Controlul Unei Drone pe Baza Estimarii Orientarii Capului Utilizatorului
Cuprins
1. Introducere
1.1 Contextul actual
1.2 Dronele în contextul actual
1.3 Drone programabile
1.4 Drone construite conform cerințelor aplicației vizate
1.5 Obiectivele lucrării. Prezentarea lucrării
2. Aspecte teoretice
2.1 Detecția de față
2.1.1 Detecții de față în imagini cu fundal controlat.
2.1.2 Detecții bazate pe algoritmi de învațare automată
2.1.3 Algoritmul Viola Jones
2.1.4 Caracteristici Haar
2.1.5 Algoritmul Adaboost
2.2 Estimarea orientării capului utilizatorului
2.2.1 Lucas-Kanade
3. Arhitectura aplicației
3.1 Drona bazată pe autopilotul APM 2.6
3.2 Protocol MAVLink
3.3 Arhitectură control autonom
4. Implementarea aplicației
4.1 Structura aplicației
4.2 Implementare Android. Activități principale.
4.2.1 Realizare activitate de introducere
4.2.2 Realizare activitate principală
4.3 Implementare modul de detecție utilizând OpenCV
4.3.1 Accesarea camerei folosind OpenCV
4.3.2 Procesarea cadrelor
4.3.3 Detecția de față și profile
4.3.3.1 Creare clasificator pentru detecția de profile
4.3.4 Optical Flow Lucas-Kanade
4.4 Estimarea orientării capului utilizând detecții de față și profile
4.5 Estimarea orientării capului utilizând „optical flow”
4.6 Implementare modul conexiune Bluetooth
4.7 Arduino IDE. ArduPilot v3.2.1
4.8 Preluare date de la dronă. Interpretare mesaje MAVLink.
4.8 Comanda dronă
4.9 Conexiune și comandă robot ABB pentru realizarea testării.
4.9.1 Creare server bluetooth
5.1 Instalare aplicație Android
5.2 Evaluare aplicație
6. Concluzii și dezvoltări ulterioare
6.1 Concluzii
6.2 Dezvoltări ulterioare
7. Bibliografie
1. Introducere
Contextul actual
Tehnologia actuală nu încetează să uimească prin progresul făcut în ultimii ani, un progres accelerat care aduce în vizor foarte multe echipamente avansate și aplicații care simplifică din ce în ce mai mult viață oamenilor. Toate aceste echipamente au o arie largă de domenii în care și-au găsit aplicabilitate, reprezentând o schimbare majoră a modului de desfășurare a activităților.
Accentul cade din ce în ce mai mult, în ultimul timp, pe automatizarea cât mai multor procese cu scopul de a eficientiza fluxul de construcție, în cazul realizării unor produse finite, de a elimină implicarea umană în anumite medii de lucru, dar și pentru prelucrări inaccesibile sau greu de realizat pentru un operator uman. Așadar, multe din procesele de producție, dar nu numai, sunt robotizate, contactul cu omul fiind reprezentat doar de un mediu de comunicație prin care sunt transmise comenzi sau fiind absent, toată procesarea făcându-se autonom, pe bază unor programe încărcate în echipamentele respective.
1.2 Dronele în contextul actual
O apariție notabilă, din punct de vedere al robotizării, o reprezintă dronele. Aceste echipamente, numite și „UAV”-uri („Unmanned Aerial Vehicle”)[15], sunt echipamente de zbor fără pilot la bord, pot fi controlate de la distanță prin intermediul unei stații de control de la sol, dar au și posibilitatea de zbor autonom pe baza configurației definite de utilizator. Prima apariție a dronelor a fost în domeniul militar, reprezentând un pas foarte mare în acest domeniu. Datorită multiplelor configurații în care au fost construite, domeniul de activitate s-a extins rapid și foarte mult, existând asemenea echipamente atât în agricultură, arheologie, dar și în jurnalism și alte activități asemănătoare.
O clasificare în linii mari a acestor drone ar putea evidenția două tipuri principale:
drone de recunoaștere și supraveghere : drone civile, achiziționarea unor astfel de drone este permisă oricui;
drone militare : drone construite special pentru armată, dotate cu rachete și bombe;
Din cauza numărului mare de domenii de utilizare, aceste echipamente pot fi clasificate după rolul acestora în mai multe tipuri:
drone folosite pe post de țintă : acestea pot simula ținte ale unui atac aerian și sunt folosite în diferite simulări și antrenamente;
drone de recunoaștere : sunt folosite în special pentru a supraveghea un anumit obiectiv sau o anumită zonă de interes;
drone militare : sunt capabile de a lansa un atac armat asupra unui obiectiv, au dimensiuni foarte mari și pot transporta atât rachete, cât și bombe; în prezent există peste 100 de modele de UAV-uri construite pentru industria militară;
drone folosite pentru dezvoltare și cercetare;
drone civile: sunt drone comerciale destinate aplicațiilor civile, fiind inofensive pentru cei din jur; de obicei acestea sunt orientate către o anumită funcționalitate, fiind livrate ca un produs finit;
Răspândirea atât de variată a acestor drone este susținută și de configurațiile multiple existente, din punct de vedere al construcției și al dimensiunilor evidențiindu-se: „SingleCopter” și „CoaxCopter” (au dimensiuni mici și un singur motor, fiind destinate utilizării într-o clădire) „MultiCopter” (au mai multe motoare și sunt utilizate fie pentru uz personal, fie pentru uz profesional, având o stabilitate aparte), „UAV”( sunt elicoptere sau avioane de dimensiuni variate, ajungând până la dimensiuni similare unui avion de luptă) și microdronele (au o construcție specială, fiind realizate după înfățișarea unor păsări sau insecte, de dimensiuni foarte mici; sunt foarte greu de realizat și au o autonomie foarte mică din cauza dimensiunilor lor).
Printre domeniile variate în care au pătruns aceste dispozitive se regăsesc[18]:
domeniul militar: se evită punerea în pericol a vieții piloților prin utilizarea dronelor;
domeniul securității: supraveghere, monitorizare și control;
meteorologie: importanță deosebită în studiul climei, monitorizare și colectare
informații specifice;
situații de urgență: incendii, persoane izolate în zone greu accesibile;
agricultură: monitorizare culturi;
fotografie și cinematografie: dronele au capacități ridicate de a realiza fotografii și
filmări de înaltă calitate, fiind folosite chiar pentru filmarea unor scene din filme;
domeniul vânzărilor: au fost create tot mai multe materiale promoționale cu ajutorul
acestor echipamente, materiale impresionante și convingătoare pentru clienți;
jurnalism: dispozitivele permit reporterilor să realizeze filmări inaccesibile de la sol;
în mediul comercial: o posibilitate de a livra produse cu ajutorul dronelor a fost luat
în considerare de una dintre cele mai mari companii din lume, Amazon;
Drone programabile
Cu toate că există o varietate foarte mare de modele de drone, acestea nu pot satisface toate cerințele utilizatorilor, deoarece, în general, acestea sunt construite având un singur obiectiv de îndeplinit și nu pot anticipa toate cerințele utilizatorilor. Majoritatea dronelor care se comercializează sunt construite fie pentru amuzament, fie pentru un scop bine definit, fiind livrate ca un produs finit fără posibilitatea de a fi modificate.
O soluție a acestei probleme o reprezintă dronele create după nevoile utilizatorului. Numai o mică parte a dronelor deja existente pe piață, oferă posiblititatea dezvoltării unei aplicații proprii, putând fi programate în funcție de necesitățile celui care o folosește. Din această categorie fac parte drone ca Phenox 2 și Parrot AR.
Phenox 2 [24]- fig. 1.-este o dronă custom care zboară autonom, controlul provenind exclusiv de la autopilot, independent de alte dispozitive externe. Proiectul privind realizarea acestei drone a fost lansat în Tokyo (2012), Japonia și a avansat rapid, vizând acum producția în masă a acestui tip de dronă.
Fig. 1. Phenox 2
Oferă utilizatorului care o achiziționează mai multe avantaje: este bazată pe Linux și poate transmite informații în timp real, printr-o conexiune în timp real, poate fi controlată prin aplicații de tip Android sau iOS, utilizatorul având libertatea de a alege utilizarea acestei drone, având la dispoziție și o cameră capabilă de achiziție foto și video.
Deși pare o alegere bună, există și multe dezavantaje ale acestei drone care ar trebui luate în considerare. În primul rând, datorită dimensiunilor relativ mici, drona este foarte ușor de perturbat de către factori externi precum vânt și curenți de aer. În al doilea rând, drona nu permite atașarea unor componente externe precum gimbal sau o cameră profesională GoPro, deoarece capacitățile sale de a ridica greutăți sunt limitate. De asemenea nici stream-ul video și nici fotografiile realizate cu această dronă nu au o calitate impresionantă, rezoluția acesteia fiind de numai 320 x 240. În ceea ce privește programarea acestui autopilot, utilizatorul este și aici limitat din punct de vedere al memoriei disponibile. În concluzie, raportul calitate – preț, nu susține achiziționarea unei astfel de drone, prețul său ajungând până la 1400$. Nici timpul de zbor nu reprezintă un atuu al aceste drone, fiind limitat din cauza faptului că nu poate căra o baterie Lipo foarte mare.
Parrot AR [21] – fig. 2 – face parte tot din categoria dronelor customizabile, fiind o dronă opensource pusă la dispoziție de cei de la Parrot, la un preț aproximativ de 300$, controlul acesteia putând fi făcut de pe un telefon inteligent sau de pe o tabletă.
Privită în opoziție cu Phenox 2 această oferă o cameră frontală mai bună ( 720 pixeli- 30 fps), stocarea pozelor și a filmelor făcându-se pe dispozitivul de control, dar nu are un autopilot atașat care să poată fi programat de către utilizator. Aceast lucru impune o limitare, deoarece aplicațiile pentru această drona pot fi realizate numai exploatând SDK-ul pus la dispoziție de cei de la Parrot. De asemenea, timpul de zbor reprezintă un dezavantaj și pentru această dronă, autonomia sa fiind de numai 12 minute (ultima variantă a aceste drone crește durată de zbor la 36 de minute, având două baterii atașate).
Fig. 2. Parrot AR
Din punct de vedere al sistemului de operare, acesta este bazată tot pe un kernel de Linux. Este dotată ca și Pheonx 2 cu mai mulți senzori inerțiali (giroscop, accelerometru, magnetometru, sonar). Dacă se dorește dezvoltarea unor aplicații care implică atașarea unor componente externe, această este din nou limitată, neputând fi schimbată configurația din punct de vedere al construcției, aplicațiile dezvoltate necesitând o implementare în conformitate cu capacitățile dronei de prelucrare și construcția simplistă a acesteia. Nici drona Parrot nu are răspunde bine perturbațiilor din exterior în timpul zborului, fiind ușor de perturbat.
Parrot AR este o alegere bună pentru dezvoltarea de aplicații care nu depășesc capacitățile, având un preț relativ bun, o comunitate activă destul de mare (fiind opensource), beneficiind și de foarte mult suport din partea firmei producătoare.
Drone construite conform cerințelor aplicației vizate
Dronele programabile comercializate, așa cum a fost detaliat și mai sus, au avantaje, dar și multe dezavantaje care evidențiază, în general, performanțe reduse ale camerelor, instabilitate, și diverse limitări de construcție (imposiblitatea de a adăuga elemente externe).
În vederea rezolvării problemelor expuse, este necesară construcția unei drone în conformitate cu performanțele dorite. Acest lucru presupune stabilirea unui scop binedefinit, pe bază căruia se va construi fizic drona și se vor stabili elementele hardware și software folosite.
Definirea clară a cerințelor este un element cheie în construcția unei drone. Aproape toate elementele din construcția sa au o influență directă asupra aplicației dezvoltate, și de aceea, pentru a atinge scopul stabilit, alegerea tuturor elementelor trebuie să se facă în cunoștință de cauză. Din acest punct de vedere, sunt foarte multe elemente de care trebuie ținut cont: alegerea materialului de construcție, alegerea cadrului, radio-transmițătorului și receptorului, alegerea motoarelor, alegerea autopilotului, a ESC-urilor și a bateriei, precum și a altor elemente externe și a unei game variate de senzori.
Cu toate că s-ar putea spune că materialul de construcție nu are un rol atât de important în construcția dronei, acest lucru nu este adevărat. Materialul afectează stabilitatea dronei, performanțele în zbor, dar și atingerea scopului aplicației în cazul în care aceasta presupune ridicarea și transportarea unor greutăți atașate. În cazul unor accidente neprevăzute (lovituri sau căderi de la altitudini mari), un material de construcție mai rezistent, cum ar fi fibră de carbon, ar putea fi un avantaj.
Un alt element important în crearea dronei este alegerea cadrului folosit. Există mai multe tipuri de cadre (cadre care au de la trei până la opt sau poate chiar mai multe brațe pentru motoare), dar și în această privință, alegerea trebuie făcută în funcție de aplicație. Un cadru cu trei motoare, de exemplu, nu este totdeauna alegerea cea mai bună, fiind relativ greu de controlat, iar în cazul avarierii unui motor aducerea la sol a dronei nu ar fi posibilă. Alte variante de cadre propun configurații în formă de „+”, „X” sau configurații care necesită foarte multe motoare. O configurație în formă de plus („+”) ar putea fi mai ușor de controlat în zbor, dar dacă se dorește utilizarea acesteia în aplicații care presupun achiziția video, nu este o alegere bună. O alegere câștigatoare în acest caz este configurația în formă de „X”, un cadru care are fața reprezentată de două motoare, este puțin mai greu de controlat față de cadrul în formă de „+”, dar o cameră atașată dronei pe acesta configurație ar avea o deschidere mai mare pentru achiziție video sau fotografie din cauza motoarelor plasate lateral. În cazul cadrelor care au peste opt motoare, scopul este de a avea o putere cât mai mare, o stabilitate mai ridicată în aer, fiind mai greu de perturbat, dar și un nivel de siguranță mult mai mare decât în cazul celorlalte configurații dacă unul dintre motoare se defectează. Nici partea de comunicație nu trebuie neglijată. Atunci când trebuie ales un radio-transmițător pentru control este important că acesta să ofere posibilitatea comutării între mai multe moduri de zbor (manual, automat, zbor cu menținerea altitudinii), iar frecvența aleasă ar trebui să asigure o comunicație robustă (neperturbată). O alegere sigură ar fi un radio-transmițător cu o frecvență de 24GHz.
Alegerea motoarelor este în strânsă legătură cu cerințele aplicației. În cazul în care se dorește ca drona să poată căra diferite greutăți se vor alege motoare mai puternice și va fi construit un cadru mai puternic,iar pentru o aplicație care presupune numai un zbor de agrement se vor alege motoare cu performanțe mai scăzute. Motoarele alese trebuie să nu fie foarte ușor de perturbat de curenții de aer din mediul în care zboară și nici de cei pe care îi generează elicile. Un parametru important al motoarelor care influențează și alegerea elicilor îl constituie parametru „KV”(rpm/Volt). Odată cu alegerea acestor motoare trebuie alese și controalele responsabile de transformarea semnalului primit de la autopilot în curent pentru motoare. Aceste controale se numesc „Electronic Speed Controller” (ESC).
O parte componentă cu o importanță deosebită este autopilotul. Acesta este „creierul” dronei fiind responsabil de atingerea scopului aplicației. Și acesta trebuie ales în funcție de necesități deoarece o alegere eronată poate impune limite referitoare la memoria disponibilă și la interfațarea cu alte dispozitive externe. În cazul în care dorim să utilizăm senzori sau alte elemente externe, un autopilot care recunoaște aceste elemente ar putea fi un real ajutor. Pe lângă elementele externe care pot fi atașate sau nu dronei, pe autopilotul ales pot fi mai mulți senzori încorporați, care nu trebuie neglijați (giroscop, acelerometru, barometru) sau interfețe de comunicație care pot fi utilizate în diferite combinații (I2C).
Partea de senzoristică și de alegere a autopilotului și a elementelor aduse în discuție vor fi detaliate în ceea ce privește aplicația, în capitolul „Arhitectura aplicației”, subcapitolul „Drona bazată pe APM 2.6”.
Obiectivele lucrării. Prezentarea lucrării
Scopul principal al acestei lucrări este prezentarea unui mod inovativ de control al unei drone, control care presupune o interacțiune de tipul om-dispozitiv cât mai redusã Aceastã interacțiune presupune comanda dronei prin intermediul prelucrării fluxului video achiziționat, control bazat pe estimarea orientării capului utilizatorului. În vederea atingerii acestui scop final, existã mai multe subscopuri care trebuie îndeplinite.
Aceste subscopuri includ construcția fizicã a unei drone folosind elemente achiziționate individual, gãsirea unui mod de stabilizare a dronei într-un spațiu închis, crearea comunicației cu dispozitivul mobil, atât din punct de vedere al circuitelor folosite, dar și în ceea ce privește implementarea conexiunii, folosirea unei metode de estimare a orientãrii capului și dezvoltarea unui modul de comandã a dronei, ca reacție a procesãrilor fãcute.
Determinarea cu exactitate a unghiurilor de rotație reprezentate în figura 3 reprezintă o problemă foarte complexă pentru care se caută încă o soluție. Lucrarea prezentă nu prezintă o soluție pentru determinarea acestor unghiuri, subiectul tratat fiind realizarea unor estimări a mișcărilor reprezentate, în vederea controlului dronei. Astfel sunt estimate mișcări de „pitch” și „yaw” folosind detecții de față frontală, profil stânga, profil dreapta și urmărirea unor puncte de interes determinate pe față.
Fig. 3. Tipuri de mișcări estimate
În capitolul „Aspecte teoretice” vor fi prezentate aspecte teoretice ale programelor folosite în dezvoltarea aplicației, ale librăriilor folosite, precum și noțiuni teoretice din sfera detecțiilor de față și a algoritmilor existenți.
Capitolul „Arhitectura aplicatiei” prezintă drona creată în detaliu, în ceea ce privește autopilotul și porturile de comunicație de care acesta dispune, precum și protocolul de comunicație existent pe acesta și modul de realizare a comunicației între telefonul mobil și dronă (module auxiliare folosite și interacțiunea dintre acestea).
Implementarea aplicației în ceea ce privește prelucrarea fluxului video, realizarea comunicației, preluarea datelor și modul de comandă vor fi prezentate în capitolul „Implementarea aplicatiei”.
Rezultatele obținute și detalii despre utilizarea aplicației pot fi regăsite în capitolul „Utilizarea și evaluarea aplicatiei”.
Concluziile rezultate în urma dezvoltării precum și dezvoltări ulterioare posibile pentru această aplicație, sunt prezentate în capitolul „Concluzii și dezvoltări ulterioare”. Referințe utile pot fi găsite în ultimul capitol al aceste lucrări.
2. Aspecte teoretice
2.1 Detecția de față
Detecția de față presupune identificarea și localizarea într-o imagine a fețelor umane în diferite condiții de iluminare, în diferite poziții și orientări precum și în funcție de dimensiunea feței conținută în imagine. Se pune foarte mult accent pe analiza comportamentului omului în vederea realizării unor sisteme inteligente care să se apropie de comportamentul uman cât mai mult. Detecția unei fețe este o sarcină foarte ușoară pentru un subiect uman, dar devine o provocare atunci când trebuie realizată de un simplu calculator. Putere de procesare oferită de calculatoare nu mai reprezintă o problemă, așa cum se întâmpla mai demult, dar detecția de față este încă un subiect discutat.
Există o diferență foarte mare între modul în care este percepută o imagine de către creierul uman și de către un calculator. Omul percepe imaginea sub formă de informație luminoasă și este înțeleasă imediat, spre deosebire de un calculator unde imaginea este reprezentată de o matrice de valori ce reprezintă nivelul de gri ale fiecărui pixel (imagine digitală). De exemplu, figura 4 reprezintă percepția umană, iar figura 5 reprezintă o imagine digitală (valorile fiecărui pixel din imagine).
Fig. 4. Percepție umană Fig. 5. Imagine în format digital
Există foarte multe mulți factori care afectează problema detecției de fețe. Dintre acești factori putem menționa gradul de iluminare al imaginii. Deși se poate ca ochiul uman să nu perceapă o schimbare mică la acest nivel, în imaginea digital valoarea pixelilor o să fie schimbată. Din cauza problemelor de acest gen, detecțiile de față necesită algoritmi robuști, algoritmi care să poată recunoaște fețe și în cazul în care imaginile sunt excesiv luminate sau prea întunecate.
Problema detecției de fețe la momentul actual, oferă o rată de detecții pozitive de 85% și o rată de detecții false de sub 5%, în cazul imaginilor. Pentru procesarea în timp real, au fost atinse performanțe de 40ms pentru detecție în cazul unor cadre preluate de la o cameră VGA.
Printre multitudinea de abordări a acestei probleme se innumara detecția feței bazată pe detecția de piele din imagine (metoda Kovac et al.[16], metoda Brown et al.[5], Jones-Rehg[19]), detecții pentru imagini color și pentru imagini reprezentate cu niveluri de gri ( metode bazate pe cunoștințe, pe trăsături, abordări de tipul „template matching” sau metode bazate pe aspect).
2.1.1 Detecții de față în imagini cu fundal controlat.
Aceasta este una dintre cele mai simple formulări ale problemei de detecție de față. Detecția se bazează pe crearea unui fundal controlat, un fundal care să nu conțină alte obiecte și să aibă o culoare diferită față de nuanțele de piele. Acest proces de detecție se bazează pe detecția de piele și de aceea este important ca fundalul imaginii să fie unul adecvat.
Detecția de piele este procesul care găsește, în cadrul unei imagini sau în cadrele unui film, pixeli și regiuni de culoarea pielii. Este, în principal, un proces ce se folosește în primă fază pentru procesarea imaginilor care conțin fețe umane, de exemplu, sau alte părți de interes ale corpului uman. La nivelul algoritmilor care se ocupă de această detecție, abordarea presupune clasificarea fiecărui pixel ca fiind sau nu pixel de piele, pe baza valorii pe care o are acesta.
Detecția de piele poate fi aplicată în diferite spații de culoare: RGB (spațiul tuturor aparatelor de achiziție), spații de culoare derivate din RGB (ZYX, YIQ, YUV – pun accent pe luminanță Y), spații perceptuale (HSV – luminanță, saturație și nuanța) și uniform-perceptuale (CIE – bazate pe distanță euclidiană). În funcție de aceste spații de culoare pielea este sau nu mai bine separată față de celelalte detalii din imagine.
Mediul în care sunt aplicate detecțiile de piele este foarte important. Într-un mediu controlat (un fundal ales care să aibă o culoare diferită față de nuanțele de piele, de exemplu gri, negru și lumina corespunzătoare), detecția de piele este suficientă pentru localizarea fețelor în imagine având o performanță chiar ridicată, însă atunci când nu se ține cont de cadrul de utilizare, performanțele pot scădea destul de mult. Datorită faptului că există foarte multe lucruri din viață reală care au culoarea în nuanțe foarte apropiate de piele, un detector bazat pe piele într-un cadru necontrolat nu este eficient. În principal, un astfel de detector este utilizat ca un un filtru în cadrul altor detecții pentru a reduce din detalii și pentru a scădea timpul de procesare.
Algoritmii de detecție de piele depind foarte mult de condițiile de iluminare și din această cauză s-a încercat dezvoltarea unor metode care să elimine această problemă.
Metoda Kovac et al.[16] prezintă abordarea problemei din două perspective, folosindu-se de reprezentarea în spațiu RGB a două tipuri de imagini: imagini care au fost achiziționate în lumină naturală (lumina zilei) și cu ajutorul unui aparat cu bliț. Pentru aceste două cazuri, Kovac determină două seturi de relații cu ajutorul cărora se determină dacă un pixel este sau nu pixel de piele. Aceste seturi conțin diferite paguri pentru valorile R,G,B și diferite relații definite între acestea, determinând un interval de variație al pixelilor ce reprezintă piele. Performanțele date de această metodă sunt slabe, datorită simplității de definire a relațiilor respective.
O altă abordare în detecția de piele este adusă de către Brown et al. [5] care folosește o rețea neurală cu auto-organizare. Acest tip de rețea păstrează topologia spațiului de intrare, actualizând ponderea nodului care determină piele, dar și a vecinilor săi.
Jones și Regh [19] propun o altă metodă de detecție de piele prin analiza culorilor dintr-o bază de date formată din foarte multe imagini preluate de pe internet. Zonele de piele din imagini au fost marcate manual, iar detecția propriu-zisă se bazează pe modelarea histogramelor de piele și non-piele cu ajutorul mai multor moduri gausiene.
În ceea ce privește detecția de față pe imagini color, apar probleme precum separarea greoaie a feței de celelalte elemente apropiate ca nuanță din imagine, precum și gruparea elementelor ce aparțin aceleași fețe și au fost separate (fața este ”sparta” în mai multe părți). Pentru aceste cazuri se pot elimina pixeli care au valori sub un anumit prag, dar performanțele nu sunt mulțumitoare în cele mai multe cazuri, sau se poate resegmenta zona de piele pe baza culorii. Această resegmentare este prezentată de Albiol et al. [1].
Metodele prezentate mai sus sunt metode ce se aplică, în general, în cazul unor medii controlate, acolo unde putem construi scena pentru a obține cele mai bune performanțe. Aceste metode vizează cazuri ideale, dar, în realitate, sunt puține momente în care putem controla mediul de achiziție al imaginilor. Pentru cazurile în care achiziția nu este controlată, s-au dezvoltat algoritmi avansați de detecție de fețe ce nu mai folosesc detecția de piele în vederea obținerii feței. Informațiile legate de culoare sunt ignorate, procesările necesare detecției făcându-se pe imagini reprezentate cu niveluri de gri.
În cazul imaginilor reprezentate utilizând niveluri de gri există mai multe metode ce se bazează pe modele predefinite sau pe clasificatori de tip cascadă antrenați pe un set de date impresionant și cu performanțe de detecție foarte bune. În general aceste metode vizează prelucrarea în timp real, spre deosebire de cele prezentate anterior, și rate de detecții pozitive cât mai bune.
O metodă bazată pe modele a fost dezvoltată de Bernhard Fröba și Christian Külbeck [3], articolul lor prezentând o metodă de detecție a feței, în timp real, bazată pe informații de orientare date de muchiile feței. Algoritmul este bazat pe ”template matching” iar, în urma testelor efectuate pe aproximativ 17000 de imagini, rata de detecție a fost de 93%. Imaginile preluate conțin variații ale dimensiunii fețelor, ale luminii și ale fundalului folosit.
Oliver Jesorsky, Klaus J. Kirchberg si Robert W. Frischholz [20] prezintă o altă metodă de detecție de față utilizând distanța Hausdorff. Această distanță este folosită pentru a măsură gradul de similitudine între un model predefinit și o reprezentare oarecare a feței într-o imagine. Implementarea acestui algoritm are ca scop o detecție în timp real, invariantă la lumină și modificări ale fundalului. Metoda dezvoltată este bazată tot pe informații date de muchiile feței.
Unul dintre cel mai comun algoritm folosit pentru detecția de fețe în timp real este cel dezvoltat de Viola & Jones [22], fiind bazat pe un clasificator cascadă format din trăsături ”slabe” alese. Acest algoritm are performanțe impresionante în cazul în care este antrenat pe un set de date foarte mare și variat.
2.1.2 Detecții bazate pe algoritmi de învațare automată
Datorită faptului că există foarte multe aspecte care trebuie luate în considerare este foarte dificil, aproape imposibil, de creat un algoritm universal pentru detecția de față.
În dezvoltarea multor algoritmi de acest tip, a stat la bază detecția de piele. Pe baza ei s-au obținut algoritmi cu diferite performanțe de detecție, dar nu cei mai buni algoritmi deoarece pot exista obiecte de culoarea pielii care să nu fie fețe, sau variații de lumină care să influențeze foarte mult această detecție. De aceea, trecerea a fost făcută, către imagini reprezentate cu niveluri de gri renunțându-se la informația de culoare. Algoritmii dezvoltați pentru analiza acestor imaginii sunt algoritmi care se bazează pe diferite trăsături identificate în imagine. În principal, acești algoritmi sunt algoritmi de învățare automată.
Similar oamenilor, și calculatoarele trebuie să învețe pentru a putea rezolva această problemă și astfel, detecția de față, devine prin folosirea algoritmilor de învățare automată, o problemă de creare a unei baze de date foarte mare și foarte variată. Acest set de date ar trebui să îi permită calculatorului să facă diferența între existența unei fețe și absența acesteia. În cazul algoritmului de detecție de față, baza de cunoștințe cuprinde foarte multe poze împărțite în două mari categorii: ceea ce numim „poze pozitive” și de asemenea „poze negative”. Noțiunea de „poza pozitivă” face referire la poze care conțin obiectul de interes, în cazul meu, poze care conțin fețe. La polul opus, noțiunea de „poza negativă” este ușor de intuit, reprezentând poza care nu conține obiectul de interes în aceasta, adică poze care nu conțin fețe.
2.1.3 Algoritmul Viola Jones
Unul dintre cei mai performanți, eficienți și robuști algoritmi de detecție, care se folosește de aceste noțiuni, este algoritmul Viola Jones. Acest algoritm a fost implementat în anul 2001 de către Paul Viola și Michael Jones [23], fiind orientat la început pe detecția de obiecte oarecare în diferite imagini și perfecționat apoi pentru detecția de fețe. Pe lângă eficiența sporită a acestui algoritm, se remarcă și viteza de detecție foarte mare, precum și acuratețea de detecție. Alți algoritmi existenți care au la bază același principiu (algoritmii Sung-Poggio [28] și Rowley-Baluja-Kanade [11]) au performanțe foarte bune în ceea ce privește rata de detecție corectă și de detecție eronată, dar nu pot fi implementate în timp real, chiar dacă se fac compromisuri în ceea ce privește rezoluția imaginii( 320×240).
Principalele probleme pe care și le pune algoritmul Viola Jones sunt:
calculul trăsăturilor ce pot caracteriza o față, precum și o metodă de calcul rapidă;
filtrarea trăsăturilor în vederea alegerii trăsăturilor care caracterizează cel mai bine o față (trăsături distinctive);
implementarea în tip real;
Ca soluții a acestor probleme au fost alese caracteristicile de tip Haar aplicate pe o imagine prelucratã anterior (imagine integrală), clasificatorul de tip AdaBoost pentru alegerea celor mai bune caracteristici și o cascadã de clasificatori ce rezolvã problema rulãrii în timp real.
2.1.4 Caracteristici Haar
Acest detector se bazează pe analiza caracteristicilor cunoscute sub numele de „Haar-like features” și nu pe analiza imaginii în sine. Aceste caracteristici sunt analizate pe imagini în care este neglijată culoarea, pe imagini în care apar doar nivele de gri, deoarece în felul acesta, algoritmul poate avea o arie largă de aplicare. Reprezentarea acestor caracteristici este făcută sub forma unui număr de dreptunghiuri. În general calculul acestor caracteristici este reprezentat de diferența între sumele pixelilor din dreptunghiuri. Figura 2.1 prezintă principalele moduri de reprezentare a caracteristicilor Haar, conform articolului „Robust real-time Object Detection”[23] ai cărui autori sunt chiar dezvoltatorii acestui algoritm Paul Viola și Michael Jones.
Fig. 6 a) Fig. 6 b) Fig. 6 c) Fig. 6 d)
Fig. 6. Tipuri de caracteristici Haar. Figurile 6 a) și 6 b) sunt reprezentări ale caracteristicilor utilizând două dreptunghiuri („two-rectangle features”) de reprezentare. În acest caz calculul este reprezentat calcularea diferenței dintre suma pixelilor cuprinși în dreptunghiul negru și suma pixelilor din interiorul dreptunghiului alb. Figurile 6 c) și 6 d) sunt reprezentări care utilizează trei, respectiv, patru dreptunghiuri („three/four-rectangle features”), dar metoda de calcul vizează tot calculul diferenței dintre suma pixelilor conținuți de dreptunghiurile negre și suma pixelilor conținuți de cele albe. Pentru rezoluția standard a detectorului de 24×24 pixeli, pot exista până la 45,396 de astfel de caracteristici, conform aticolului referit mai sus, blocurile definite fiind de aceeași dimensiune și aceeași formă.
Pentru a fi ușurat calculul caracteristicilor, este folosită o „imagine integrală”. Această reprezentare este o suprapunere peste imaginea originală în care fiecare punct preia valoarea sumei valorilor pixelilor situați în stânga și deasupra punctului considerat. Denumirea de „imagine integrală” este apropiată noțiunii de integrală definită în matematică, calculul ariei de sub curbă fiind realizat prin suma de dreptunghiuri. O reprezentare a acestor calcule poate fi găsită în reprezentarea din figura 7: pentru regiunea marcată cu 1, valoarea din punctul A este suma pixelilor din această regiune; valorile din punctele B și C pot fi scrie ca sumă de două regiuni, 1 + 2, respectiv 1 + 3, iar valoarea din punctul D ca sumă celor 4 regiuni (1 + 2 + 3 + 4). Se observă cu ușurință că suma din regiunea 4 poate fi calculată utilizând o relație între cele patru puncte definite: D + A – ( B + C ).
Fig. 7. Metoda de calcul a regiunii 4.
2.1.5 Algoritmul Adaboost
Având în vedere numărul mare de caracteristici rezultate, se pune problema filtrării acestor caracteristici în vederea alegerii celor mai bune caracteristici care oferă performanțe ridicate de detecție și un cost scăzut din punct de vedere al timpului de execuție.
Algoritmul Adaboost este algoritmul de inteligență artificială, formulat inițial de către Yoav Freund și Robert Schapire [32] care presupune combinarea caracteristicilor considerate slabe pentru a forma un clasificator mai puternic. Acesta se ocupă și de procesul de antrenare. Noțiunea de „caracteristică slabă” provine de la valoarea ponderii asociate în procesul de antrenare fiecărei caracteristici de tip Haar, această valoare fiind mică. O „caracteristică puternică” este reprezentată de o caracteristică Haar care are o pondere mare. Ponderile asociate fiecărei caracteristici sunt actualizare în timpul procesului de antrenare, evidențiind acele trăsături pentru care detecția a fost incorectă pentru a fi reevaluate. Această reevaluare presupune construirea unui „clasificator în cascadă”, rejecția pozelor negative fiind realizată treptat în această cascadă, pe baza ponderilor asociate.
Conform articolului „Robust real-time Object Detection”, ponderile sunt inițializate, la începutul procesului de antrenare, în funcție de numărul de poze negative și poze pozitive (1), urmând ca apoi acestea să fie normalizate (2). În urma normalizării este creat câte un clasificator pentru fiecare trăsătură, care nu poate folosi decât un singur tip de caracteristică (3). Clasificatorul care are cea mai mică eroare este ales, ponderile sunt actualizate (4), rezultând în final un clasificator puternic (5).
Algoritmul Adaboost poate fi urmărit în figura 8.
Fig. 8. Modul de aplicare al algoritmului Adaboost
Conform experimentului inițial prezentat în articolul „Robust real-time Object Detection” [23], un clasificator format pe baza a 200 de caracteristici avea o rată de detecție de 95%.
Clasificatorii Haar și algoritmul Adaboost sunt elemente foarte importante în realizarea detecțiilor deoarece pot fi folosite în detectarea tuturor obiectelor dorite. OpenCV pune la dispoziție mai mulți clasificatori, în special pentru detecție de față sau elemente ale feței (ochi, gură, nas), dar și câteva instrumente prin care pot fi create clasificatoare similare pentru detecții de alte obiecte.
2.2 Estimarea orientării capului utilizatorului
Capacitatea de a estima poziția capului este o capacitate comună pentru subiecții umani, dar reprezintă o provocare pentru sisteme care analizează acest lucru folosind algoritmi de inteligență artificială. Comparativ cu detecția de față pentru care s-au găsit mai multe soluții cu performanțe mulțumitoare, problema estimării orientării capului utilizatorului încă nu are o soluție riguroasă.
Există numeroase interpretări pentru această problemă, fiecare dintre acestea având nu anumit grad de dificultate. Într-un caz simplificat, estimarea orientării poate fi realizată în linii mari prin detecția de față frontală, profil stânga sau profil dreapta. Într-un caz mult mai complicat, soluția presupune determinarea unghiului cu care este rotită față având în vedere gradele de libertate avute. Un sistem mai simplist poate analiza mișcarea pe un singur grad de libertate, de exemplu de la stânga spre dreapta, spre deosebire de un sistem complex care poate face o estimare 3D a orientării și poziției.
În contextul inteligenței artificiale, estimarea orientării capului este interpretată ca fiind abilitatea de a determina orientarea capului referitor la camera folosită. O abordare riguroasă ar presupune o estimare având ca referință un sistem de coordonate global, dar acest lucru presupune cunoașterea parametrilor pe care îi are camera. În mod normal un om poate roti capul prin îndoirea gâtului între −60.4◦ si 69.6◦ (de la dreapta la stânga ), si de-a lungul orizontalei între −79.8◦ și 75.3◦ [10].
Mișcarea capului uman are numai trei grade de libertate cunoscute, în engleză, sub denumirile: „pitch”, „roll” și „yaw”. Există mai multe tipuri de abordări care încearcă estimarea acestor tipuri de mișcări. Dintre aceste abordări fac parte:
metode bazate pe „template” : sunt metode ce presupun compararea unei imagini cu un set de exemple marcate pentru a găsi exemplul cu care se potrivește cel mai bine determinând în acest fel poziția capului („Mean Squared Error”, „Normalized Cross-Correlation”)ș
metode bazate pe algoritmi de învățare automată și rețele neurale: au la bază un set de date de antrenare pe baza cărora se face apoi determinarea poziției ( „SVM” sau „Adaboost Cascades”);
metode bazate pe trăsături: se folosesc de localizarea ochilor, nasului, gurii pentru a determina pozitita capului în funcție de o configurație definită;
metode de urmărire: presupun o analiză a mișcării de-a lungul mai multor cadre preluate. Se bazează pe diferența de mișcare dintre cadre;
metode hibride: sunt metode ce îmbină mai multe tehnici, de tipul celor prezentate pentru a elimina anumite probleme, crescând astfel performanțele de detecție;
2.2.1 Lucas-Kanade
În ceea ce privește determinarea în timp real a orientării capului utilizatorului, o soluție a acestei probleme constă în aplicarea conceptului de ”optical flow„. Acest concept constă în analizarea a două cadre succesive în vederea determinării mișcării, mișcare cauzată de deplasarea unui obiect sau a camerei folosite pentru achiziționarea cadrelor. Aplicarea acestui concept are ca scop deteminarea mișcării anumitor puncte de la un cadru la altul.
În cazul imaginilor statice, timpul nu este adus în discuție, în schimb, în cazul unei prelucrări în timp real, acesta este un element foarte important. Pentru o utilizare cât mai simplă a acestui concept, au fost dezvoltate metode în cadrul bibliotecilor care se ocupă de prelucrarea video. Printre aceste biblioteci se află și OpenCV. Deși marchează partea matematică, aceasta este detaliată în documentația oficială [31].
Figura 9 [31] prezintă vectorul de mișcare al unei mingi în urma unei analize făcute pe cinci cadre succesive. Pentru a avea rezultate bune în urma aplicării acestui proces, s-a presupus că intensitatea pixelilor, ce descriu obiectul urmărit, nu se schimbă semnificativ între doua cadre consecutive și că pixelii vecini au o mișcare similară.
Fig. 9 Vector de mișcare al unei mingi pe parcursul a cinci cadre succesive.
(Imagine preluată [31]).
Așadar, dacă ținem cont de presupunerea conform căreia intensitatea unui pixel nu se modifică semnificativ între două cadre succesive, putem spune că acesta s-a mișcat cu o anumită distanță, în spațiul 2D în timpul [31] .
Dezvoltând în serie Taylor și raportând la timpul , obținem o ecuație cu două necunoscute ce nu poate fi rezolvată prin metodele clasice: , unde , , sunt gradienți (spațiali și temporali) și , sunt necunoscutele.
O soluție a acestei ecuații este dată de metoda Lucas-Kanade[4]. Această metodă are ca scop creșterea numărului de ecuații pentru necunoscutele precizate mai sus în vederea determinării soluției. Sunt folosiți pixeli vecini pentru a ajunge la relațiile ajutătoare, cu presupunerea că un anumit număr de pixeli vecini au aceeași mișcare ca și pixelul înconjurat. Unul dintre cele mai simple sisteme rezultat cu această metodă este determinat considerând un bloc de 3×3 ce înconjoară pixelul vizat. Astfel vor rezulta nouă ecuații cu ajutorul cărora vor fi determinate necunoscutele. De obicei, metoda Lucas-Kanade folosește blocuri de dimensiuni mici pentru a calcula optical flow, acestea putând fi folosite indiferent de dimensiunea imaginii. Această metodă este o metodă ajutătoare în calculul vectorilor de mișcare (”optical flow vectors”) pentru un set de puncte căutat sau furnizat de către utilizator.
3. Arhitectura aplicației
Aplicația dezvoltată urmărește estimarea mișcării capului utilizatorului pentru a putea controla autonom drona construită. Astfel estimarea mișcării utilizatorului este realizată prin prelucrarea fluxului video de pe telefonul mobil. În urma acestei procesări se crează și se trimit comenzi de mișcare pentru dronă, comenzi conforme cu estimarea făcută. Figura 10 prezintă mișcările estimate și reacțiile așteptate de la dronă. O mișcare a utilizatorului la stânga este interpretată și ar trebui să genereze o mișcare la stânga a dronei, lucru care se realizează prin intermediul autopilotului.
Telefonul mobil are un rol foarte important în această aplicație. Cu ajutorul acestuia se realizează atât prelucrarea în timp real a fluxului video, cât și crearea comenzilor și trimiterea acestora către autopilotul dronei. Autopilotul recepționează comanda și, ca răspuns, furnizează putere motoarelor pe canalele corespunzătoare. Transmisia și recepția comenzii se realizează prin intermediul conexiunii bluetooth și a modulelor auxiliare folosite.
Fig. 10. Structura aplicației
Arhitectura aplicației este prezentată și în figura 11. Acesta presupune achiziția cadrului, procesarea lui, determinarea orientării și a comenzii aferente care va fi trimisă la dronă, procesul reluându-se cu următorul cadru.
Fig. 11. Arhitectura aplicației
Această lucrare nu presupune numai aplicarea unor algoritmi de detecție sau antrenarea unor astfel de algoritmi, întregul ansamblu fiind mult mai complex. Pe lângă telefonul mobil ca parte a acestui sistem, alte două părți fără de care nu ar putea fi atins scopul acestei lucrări sunt reprezentate de dronă și de partea de comunicație prin care sunt legate procesarea de pe mobil și comanda dronei. Această comunicație este reprezentată în figura 12.
Există două moduri de control care pot fi accesate. Unul dintre acestea este cel clasic, pe baza telecomenzii, iar celălalt este reprezentat de controlul prin intermediul telefonului mobil. Pentru cel de-al doilea, și pentru a putea schimba între aceste două moduri, a fost necesară construirea unui circuit auxiliar. Acest circuit auxiliar conține mai multe module care sunt reprezentate în figura 12 ca mod de comunicație și detaliate în continuare acestei lucrări pentru a evidenția scopul folosirii lor.
Fig. 12. Arhitectura de comunicație (modul de transmisie comenzi).
3.1 Drona bazată pe autopilotul APM 2.6
Partea cea mai importantă aceste drone, pe lângă partea de construcție (alegere cadru, motoare, elici etc.), este reprezentată de către autopilot. Acesta poate impune anumite limitări și de aceea este foarte important ca acesta să fie ales după ce s-au stabilit cerințele aplicației. Nu există, momentan, foarte multe variante comercializate care să îi permită utilizatorului dezvoltarea de aplicații utilizând soft-ul existent sau exitinzand acest soft. Dintre acestea fac parte: KK2, CC3D, Naze32, Naza, APM, Crius AIO Pro, Brain FPV s.a.
Am ales pentru dezvoltarea acestei aplicații autopilotul oferit de cei de la ArduPilot [14] care este o variantă actualizată a unei versiuni mai vechi (APM 2.5). Versiunea 2.6 oferă în principal aceleași facilități ca și versiunea 2.5, dar spre deoasebire de aceasta, ultima versiune apărută este construită astfel încât să folosească un magnetometru extern pentru a evita eventualele interferențe magnetice ce pot să apăra. Acest pilot nu necesită achiziționarea unei licențe pentru a putea fi programat după propriile dorințe, soft-ul fiind accesibil pentru orice utilizator. Autopilotul poate fi folosit pentru a controla de la distanță mașini, avioane sau multicoptere. Principalele porturi pe care le pune la dispoziție plăcută APM 2.6 sunt prezentate în figura 13.
Fig. 13. Prezentare autopilot APM 2.6 (intrări și ieșiri).
Cele mai importante dintre toate aceste porturi sunt:
portul de alimentare prin intermediul căruia este făcută alimentarea de la baterie a circuitului;
portul USB care oferă pe lângă alimentarea de 5V a plăcuței, posibilitatea de recriere a softului sau de a preluare a datelor de zbor (date furnizate de către senzori);
portul de telemetrie este responsabil de furnizarea datelor de zbor;
portul GPS este portul prin care poate fi conectat un GPS extern configurației avute.
Din punct de vedere al circuitului electric, cei de la 3D Robotics pun la dispoziție schemele care stau la baza acestui autopilot pentru a putea înțelege cât mai bine construcția sa. ArduPilot Mega are mai mulți senzori încorporați accelerometru, giroscop și un barometru de înaltă performanță. Restul senzorilor, GPS, sonar sau senzor optic pot fi atașați extern.
APM 2.6 conține pe placă un circuit care înglobează pe aceeași pastilă de siliciu și accelerometru și giroscopul. Acest circuit MPU-6000/MPU-6050 [8], este primul și singurul circuit care permite o monitorizare a mișcării pe 6 axe, fiind conceput astfel încă să consume puțin, să fie accesibil din punct de vedere al prețului și să ofere performanțe ridicate. În construcția sa conține un giroscop pe trei axe și un accelerometru pe trei axe, împreună cu un procesor încorporat „Digital Motion Processor”. Acest circuit oferă și două magistrale importante pentru interfațări ulterioare: I2C sau SPI. Intervalele de variație ale giroscopului și accelerometrului pot fi setate în funcție de performanțele de zbor dorite. Astfel se pot stabili limite pentru giroscop în intervalele: ±250, ±500, ±1000 și ±2000As/sec, iar pentru accelerometru: ±2g, ±4g, ±8g și ±16g.
Barometrul prezent pe această versiune de APM este un circuit MS5611-01BA03 [9] este noua generație de altimetru de înaltă perfomanță, oferit de cei de la MEAS Switzerland, un circuit care pune la dispoziție atât o interfață SPI cât și una I2C. Modulul include un senzor de presiune și un ADC pe 24 de biți cu parametrii calibrați din fabrică. Acesta redă presiunea, temperatura și are mai multe moduri de utilizare care îi permit utilizatorului optimizări din punct de vedere al vitezei și al consumului. Circuitul MS5611-01BA03 poate interfața cu orice microcontroler deoarece protocolul de comunicație este simplu și nu necesită rescrierea regiștrilor interni ai circuitului.
Parte din configurația dronei sunt și doi senzori externi: sonar și senzorul optic(„optical flow”). Senzorul de ultrasunete folosit este senzorul HC-SR04 [7] și funcționează pe principiul sonarului pentru a determina distanța până la un anumit obiect. Acesta poate determina distanțe din intervalul 2-400 cm, având o precizie de 3mm. Modulul HC-SR04 include atât partea de transmisie cât și partea de recepție. Senzorul de optic ADNS-3080 [12] permite menținerea unei altitudini prestabilite sau evitarea de obstacole. Acest senzor are o viteză foarte mare de detecție de 6400 fps, o rezoluție de 30×30 pixeli, o lentilă de 8 mm și o interfață SPI care permite conectarea la microcontrolerul dorit.
Modul de GPS, extern pentru versiunea APM 2.6 pentru a evita interferențele magnetice datorate magnetometrului, redă poziția folosindu-se de două coordonate: latitudine și longitudine. Funcționarea acestui dispozitiv presupune detecția sateliților pentru a putea fruniza datele dorite, de aceea nu este recondat utilizărilor în încăperi sau spații închise. Proporția în care poate fi folosit acest modul, sau o parte din funcționalitatea lui, este de 14%, așa cum susțin cei de la ArduCopter în interiorul unei încăperi, pe când în exterior această este de 99% în aer liber și de 83% în jurul unor clădiri.
Pentru o utilizare normală, calibrarea și configurarea parametrilor aceastui autopilot are și un soft disponibil. Acesta se numește Mission Planner și permite setarea diferiților parametrii de zbor, a modurilor de zbor sau salvarea datelor de zbor pentru interpretări ulterioare în fișiere de „log”.
Drona construită este prezentată în figura 14.
Fig. 14. Drona construită
3.2 Protocol MAVLink
MAVLink este un protocol de comunicație pentru UAV-uri care a fost lansat în anul 2009 de către Lorenz Meier. Este folosit în special pentru a face legătură între stația de control (GCS) și UAV, putând fi folosit pentru a transmite date legate de orientare, localizare și viteză. Acest protocol este utilizat în majoritatea aplicațiilor care presupun existența unei comunicații între dronă (sau un sistem similar) și stația de control. Este folosit, de exemplu, de autopiloți proveniți de la producători ca: Parrot AR. Drone, ArduPilot, PX4FMU, SmartAP s.a.
Protocolul prin care comunică stația de control, reprezentată de softul Mission Planner, cu APM 2.6, este protocolul MAVLink[27] (Micro Aerial Vehicle Link). Acest protocol se bazează pe trimiterea de mesaje. Aceste mesaje sunt trimise sub formă unor șiruri de biți prin intermediul telemetriei sau prin intermediul USB-ului. Este important de precizat că odată ce a fost făcut conexiunea pe USB, telemetria va fi ignorată.
Structura mesajului transmis nu este aleatoare. Acesta are o lungime fixă de 17 biți fiecare dintre acești 17 biți având o semnificație specifică. Așadar șase biți reprezintă informația din „header”, următorii nouă biți reprezintă informația transmisă, iar ultimii doi biți sunt reprezentați de sumă de control („check sum”) care ajută la detectarea erorilor de transmisie. Semnificația biților este următoarea:
bitul 0 – „header”-ul mesajului, are întotdeauna valoarea 0xFE;
bitul 1 – lungimea mesajului (aceasta este de nouă biți);
bitul 2 – numărul secvenței cu o valoare cuprinsă între 0 și 255
bitul 3 – identificatorul sistemului (sursa de la care provine mesajul);
bitul 4 – identificatorul componentei (subsistemului);
bitul 5 – identificatorul mesajului; fiecare mesaj are un identificator unic pentru a putea fi interpretat;
biții 6 – 14 – datele transmise;
biții14 – 16 – suma de control;
Rata de transmisie a mesajelor pentru telemetrie este de 57600. Atunci când ajunge la sursă mesajul este decodificat și este extrasă informația transmisă. Există foarte multe mesaje care pot fi trimise prin acest protocol pentru a permite trimiterea anumitor date sau realizarea unor configurații dorite.
Unul dintre cele mai importante mesaje ale acestui protocol este mesajul numit ”heartbeat”. Acesta este trimis de către stația de control, la fiecare secundă, pentru a verifica dacă există o conexiune între GCS și autopilot. În cazul în care se pierde o parte din mesajele ”heartbeat”, drona poate urma un zbor de siguranță aterizând, continuând zborul sau reîntorcându-se la punctul de plecare, în funcție de caz.
Există mesaje speciale pentru partea de achiziție de date de la senzori, de la GPS sau diferite mesaje de control, toate acestea având un identificator unic.
3.3 Arhitectură control autonom
Problema controlului autonom impune, pe lângă procesarea video de pe platformă Android și o modificare a arhitecturii de comunicație existentă, astfel încât utilizatorul să poată primi date de zbor pe telefonul mobil și să poată trimite comenzi către autopilot în urma procesării făcute.
Primul lucru care trebuie făcut este schimbarea modului de comandă de pe manual (comanda cu ajutorul telecomenzii prin intermediul receptorului cu 6 canale -„HK6S”), pe telefon. Din acest motiv avem nevoie de module auxiliare prin care să putem schimba modul clasic de comandă.
Figura 15 pune în evidență modulele folosite și modul în care acestea interacționează între ele. Comanda inițială bazată pe telecomandă și pe receptorul HK6S este acum înlocuită de o comandă ce se realizează prin intermediul unui modul de bluetooth. Nu există probleme de conectivitate între acest modul și telefon în ceea ce privește distanță, deoarece telefonul este atașat dronei pe gimbal.
Există trei module importante în această configurație: modulul de „Bluetooth”, modulul Maestro și un „switch Pololu 4 – Channels”.
Modul de „Bluetooth”, HC-05 [17] este responsabil de asigurarea conexiunii telefon-dronă. Acesta recepționează date de la autopilot de pe portul de telemetrie (portul de telemetrie, cel responsabil cu furnizarea datelor de zbor și a datelor preluate de la senzori, este legat pe pinul RX al acestui modul) și poate furniza comenzi dronei, prin intermediul modulului „Maestro”, legătura fiind făcută pe pinul TX. Este unul dintre cele mai performante module de acest tip, permițând atât modul de „slave” cât și modul de „master”. Alimentarea acestui modul se poate face de la 3.3V la 6V, rata de transmisie este setată implicit la 9600, putând fi modificată, iar parolă de conectare cu alte dispozitive (ceea ce numim „pairing” ) este 1234.
„Micro Maestro 6-Channels” este cel mai mic modul din familia „Maestro” [25] . Canalele acestui modul pot fi ieșiri directe pentru servo-motoare sau pentru ESC-uri (atunci când controlul se face utilizând o telecomandă radio), ieșiri digitale, sau intrări analogice. Acesta primește comenzile trimise prin bluetooth, pe pinul RX și furnizează patru ieșiri pentru cele patru motoare ale dronei începând cu canalul 1 (1-4). Conexiunile sunt reprezentate în figura 15. În vederea stabilirii inițializării acestui modul pentru utilizarea lui în transmisie pot fi urmărite culorile ledurilor aprinse pe plăcuță. Astfel, ledul de culoare verde va fi stins în cazul în care acest modul nu este conectat la calculator, sau va lumina intermitent în cazul unei conexiuni de acest tip existente. Orice tip de eroare apărut va fi semnalizat prin aprinderea ledului de culoare roșie. Cel mai important led este cel de culoare galbenă. Acest led redă starea în care se află modulul: în cazul în care luminează intermitent lent, rata de transmisie nu a fost detectată, modulul nu a fost inițializat și nu poate trimite semnal mai departe; în cazul în care luminează intermitent cu o frecvență proporțională cu perioadă servo-motoarelor, modulul a fost inițializat corect. Acesta este un aspect important deoarece primul pas în realizarea comunicației din cadrul aplicației Android va fi inițializarea acestui modul, iar urmărirea stării lui pe bază ledurilor este foarte ușoară. Protocolul specific acestui modul se numește „Mini SSC Protocol” și constă în transmiterea unui șir de biți : 0xAA- pentru inițializare, ca prima comandă, numărul canalului de transmisie ( în format „byte”) și valoarea dorită pentru comandă ( lungimea acestei valori este de 8 biți).
De la controlerul responsabil de preluarea datelor de la bluetooth, informațiile transmise ajung prin intermediul „Pololu 4-Channels” [26] către autopilot. Acest circuit este de fapt un multiplexor care preia datele de pe „slave” și le furnizează pe „output” pentru a deveni intrări ale autopilotului, iar apoi ieșiri pentru ESC-urile de pe motoare și în final turații pentru motoare. Unul dintre cele patru canale ale modulului este reprezentat de un canal de selecție care preia semnalul de la receptor de pe canalul cinci și face trecerea de pe telecomandă pe comanda din telefon.
Fig. 15. Prezentare schemă de comandă de pe telefonul mobil.
4. Implementarea aplicației
4.1 Structura aplicației
Aplicația dezvoltată presupune utilizarea mai multor medii de dezvoltare, mai multor API-uri și librării pentru a putea implementa toate modulele acestei aplicații. Ca și structură, aplicația principală este implementată în Android, utilizând ca mediu de dezvoltare Android Studio, iar pentru a seta trimiterea parametrilor de zbor de la dronă către aplicație soft-ul acesteia a fost rescris după diverse modificări cu ajutorul Arduino IDE.
Pe partea de Android, aceast proiect poate fi împărțit în mai multe module:
un modul de prelucrare video ce folosește librăria OpenCV pentru a realiza prelucrările dorite în timp real;
un modul ce se ocupă de conexiunea bluetooth cu drona;
un modul de preluare a datelor de la dronă care se folosește de un parser de mesaje de tipul MAVLink;
un modul ce trimite comenzi dronei;
un modul de testare ce presupune trimiterea pe serială a unor comenzi similare dronei către un robot pentru a simula mișcarea acesteia.
4.2 Implementare Android. Activități principale.
Android-ul [2] este unul dintre cele mai populare sisteme de operare pentru dispozitivele mobile, din lume, fiind bazat pe nucleu de Linux. Acest sistem de operare rulează pe o varietate foarte mare de sisteme: ceasuri inteligente („smartwatch”), telefoane inteligente de înaltă definiție, tablete, „ebook readers”, jocuri, console sau ochelari inteligenți („smartglasses”). La început Android nu a fost dezvoltat de Google, fiind ulterior achiziționat de către marea companie de la fondatorii acestuia: Andy Rubin, Nick Sears, Chris White și Rich Miner, în luna august a anului 2005. După achiziționare, a fost dat în folosință aproximativ 3 ani mai târziu.
Fiind un sistem de operare pentru care nu este necesară achiziționarea unei licențe (a fost pus la dispoziție gratis începând cu 21 octombrie 2008), permite tuturor utilizatorilor pasionați, dezvoltarea propriilor aplicații. De asemenea, pe lângă accesul liber la sistemul de operare oferit de cei de la Google, în calitate de dezvoltator poți beneficia de ajutorul unei comunității foarte mare care îți poate oferi soluții pentru problemele tale și care te poate ajuta să-ți dezvolți aplicația și chiar să o și comercializezi, dacă ideea este atractivă pentru public.
Pentru a putea dezvolta o aplicație în Android este necesar ca utilizatorul să-și configureze un mediu de dezvoltare. Acest lucru presupune instalarea mai multor pachete necesare: JDK („Java Developement Kit”), Eclipse IDE și Android SDK. „Java Development Kit” conține diferite instrumente utilizate de către mediul de dezvoltare vizual, Eclipse IDE, și de către Android SDK. De asemenea, există și o altă variantă de mediu de dezvoltare vizual, apărută recent, Android Studio care ajută utilizatorul în dezvoltarea aplicațiilor în comparație cu Eclipse IDE.
În dezvoltarea unei aplicații Android, un dezvoltator poate exploata foarte multe facilități oferite de acest sistem de operare. Acestea pot include utilizări de bază ale SDK-ului oferit, dezvoltarea de aplicații compatiblile cu mai multe telefoane inteligente, construirea unor interfețe grafice dinamice ( interfețe grafice capabile să-și actualizeze conținutul în funcție de dispozitivele pe care sunt rulate), salvarea anumitor date pe telefonul mobil, interacțiunea cu alte aplicații, distribuire de conținut sau documente („Content Sharing Apps”, „Sharing Files”), transfer de documente utilizând NFC, dezvoltarea de aplicații multimedia care implică lucrul cu camera foto, dezvoltarea diverselor aplicații grafice și a animațiilor utilizând OpenGL ES, aplicații care presupun crearea de conexiuni Wi-Fi sau sincronizări în „Cloud” și de asemenea pot include dezvoltarea unor aplicații care folosesc localizarea (pe baza GPS) sau alți senzori prezenți pe dispozitivul folosit. Pe lângă toate acestea, Android oferă și posibilitatea dezvoltării de aplicații pentru ochelari, ceasuri, televizoare sau mașini inteligente.
Implementarea aplicației are la bază platforma Android. Pentru păstrarea compatibilității între diferite versiuni de Android, versiunea minimă suportată este API 15. Această versiune garantează un nivel de compatibilitate de 90,4%, utilizatorii care au instalată o versiune inferioară nu vor putea instala această aplicație și nu o vor putea rula pe dispozitivul pe care îl dețin. În funcție de API-ul pentru care este creată aplicația, Android Studio creează structura de fișiere specifică (aceasta include fișierul de configurări -„AndroidManifest.xml”, activitatea de bază și directorul de resurse aferent versiunii folosite). Toate configurările de compilare și setările versiunii folosite sunt realizate de modulul de „Gradle”, modul specific Android Studio.
Proiectul este structurat pe mai multe pachete, fiecare pachet fiind orientat pe realizarea unei anumite funcționalități (conexiune bluetooth, comandă dronă, activitatea principală și alte fișiere necesare dezvoltării).
Aplicația realizată este formată din două activități: o activitate care conține ecranul de început al aplicației (activitate numită în engleză „splashscreen”), având rol de prezentare și rol grafic și activitatea principală care presupune accesarea camerei și prelucrarea fluxului video pentru detecția feței și determinarea orientării capului utilizatorului.
4.2.1 Realizare activitate de introducere
În vederea realizării unei noi activități în Android, este necesară crearea a două fișiere specifice. Un fisier XML care o să conțină partea grafică (”layout”), toate elementele folosite în activitatea specifică, și un fișier cu extensia ”.java” care o sa contină implementarea propriu-zisă a activității. De asemenea, activitatea creată nouă trebuie declarata și în fișierul ”AndroidManifest.xml” împreună cu toate celelalte activități avute, categoria acestora (”DEFAULT”, ”LAUNCHER”) și permisiunile aferente implementării.
Pentru realizarea primei activități am creat un nou fișier resursă de tip „layout” care conține elementele afișate pe ecran în momentul deschiderii aplicației. Declarearea acestor elemente este realizată în fișierul „splash_screen.xml” în format XML, folosind elementele grafice puse la dispoziție de Android și atributele specifice acestora. Aceste elemente sunt de tipul ”TextView” și ”ImageView”, primele permițând adăugarea unui text pe ecran, iar cele din urmă adăugarea unei imagini. Figura 16 prezintă componentele acestei activități.
Fig. 16. Componente principale ale activității de introducere
Activitatea a fost referită și în fișierul de ”AndroidManifest.xml” și a fost setată ca activitate de început, deoarece această are rol de prezentare și o durată scurtă (2 secunde), setând categoria de tipul ”LAUNCHER”. Fișierul în format XML este responsabil numai de partea grafică, partea de funcționalitate fiind reprezentată de un fișier „java” numit „SplashScreen.java”.
Crearea unei noi activități presupune extinderea clasei „Activity”, clasă de bază și implementarea metodei „onCreate”. Această metodă este invocată la crearea activității și de aceea în această metodă putem seta diferite configurații pentru activitate (afișare pe tot ecranul, afișare titlu) și obligatoriu conținutul acesteia. Conținutul activității se atașează folosind fișierul resursă creat, prin invocarea metodei „setContentView”. Accesarea fișierului de tip „layout” folosit se face prin furnizarea identificatorului unic atașat acestui fișier. La crearea unui fișier de tip resursă sunt creați identificatori unici care sunt conținuți de un fișier generat de Android numit „R”. Pentru accesarea și setarea conținutului dorit se folosește o sintaxă de tipul: „setContentView(R.layout.splash_screen)”. Scopul acestei activități este de a introduce utilizatorul în aplicație, așadar durata de afișare a acesteia este scurtă, făcându-se apoi trecerea în activitatea principală.
Activitatea de introducere conține și o animație realizată prin rotirea imaginii, folosite în jurul centrului acesteia, cu 360 de grade. Durata activității este dată de durata animației create. Pentru crearea acestei animații se construiește un fișier XML, fișier similar celui de layout, în care se definește animația dorită tot cu ajutorul unor atribute specifice Android („duration”, „fromDegrees”, „toDegrees”, „pivotX”, „pivotY”).
Pentru setarea acestei animații, trebuie creat un obiect de tipul „Animation” care încarcă prin intermediul metodei „loadAnimation” animația furnizată prin intermediul fișierului detaliat mai sus. Pornirea efectivă a animației se realizează prin setarea acesteia pe obiectul dorit, utilizând metodă „startAnimation”. Deoarece la finalul acestei animații se face trecerea către ce-a de-a doua activitate, trebuie definit un obiect „AnimationListener” care o să se ocupe de evenimente ce pot să apăra la începutul animației, la final sau în timp ce această se desfășoară. Pornirea activității principale se face pe evenimentul ce semnalizează finalul animației, prin apelarea metodei „startActivity” ce are ca parametru activitatea dorită. Este important ca activitatea de introducere să fie închisă.
4.2.2 Realizare activitate principală
Cea de-a doua activitate presupune accesarea camerei telefonului mobil. Acest lucru poate fi făcut direct din API-ul folosit, dar și prin alte librării folosite. Întrucât toată procesarea este făcută cu ajutorul bibliotecii OpenCV, și accesarea camerei este realizată tot prin intermediul acesteia.
În cadrul acestei activități se realizează atât partea de comandă a dronei și a robotului ABB folosit pentru testare, dar și partea de detecție de față frontală, profil stânga, profil dreapta și de urmărire în vederea estimării orientării capului utilizatorului.
4.3 Implementare modul de detecție utilizând OpenCV
OpenCV („Open Source Computer Vision”) [6] este o bibliotecă C++ care nu necesită licență pentru folosire, fiind accesibilă tuturor utilizatorilor („open source”) care doresc să o folosească în procesări de imagini și în implementări ce presupun „computer vision”, atât în scopuri comerciale cât și pentru uz personal. A fost inițial dezvoltată de Intel, acum fiind susținută de Willow Garage.
Această bibliotecă pune la dispoziție până la 2500 de algoritmi optimizați de învățare automată și inteligență artificială. Acești algoritmi pot fi folosiți pentru detectarea fețelor, recunoașterea lor, identificarea unor diferite obiecte, pentru clasificarea unor gesturi umane, pentru urmărirea mișcării, extragerea modelelor 3D a unor obiecte, alipirea pozelor în vederea creării unei scene complete, chiar și pentru realitate augumentata.
Comunitatea de dezvoltare a acestei librării este foarte mare, cuprinzând până la 47 de mii de contribuitori și peste șapte milioane de descărcări. Este o bibliotecă des folosită în companii sau grupuri de cercetare. Ca și limbaje de dezvoltare, poate fi folosită în C++, C, Python, Matlab și Java. Ca medii de dezvoltare poate fi uilizat Visual Studio, Eclipse sau Android Studio.
Procesul de configurare a mediului de lucru este mai anevoios dacă folosim de exemplu, Visual Studio, deoarece acesta mediu presupune setarea de variabile de mediu, diverse dependințe și specificarea fișierelor de tipul „.lib” folosite în dezvoltare. Android Studio simplifică acest proces, deoarece librăria de OpenCV are și o variantă specifică dezvoltării pe platformă Android, iar configurarea presupune importul bibliotecii ca și modul al proiectului și setarea ca dependință a acesteia. Toate acestea se fac accesând setările proiectului, configurările de compilare fiind făcute automat prin sincronizarea modulului de Gradle, modul responsabil de compilarea proiectului.
OpenCV este structurat pe mai multe module, dintre care, cele mai importante sunt:
„Core”: este modulul de bază al bibliotecii incluzând principalele tipuri de date și cele mai uzuale metode de procesare de imagini. Acesta este extins de către alte module.
„Highgui”: este modul care ii oferă utilizatorului posibilitatea de realizare a unei interfețe grafice, a unor imagini specifice, posibilitatea de utilizare a unor codecuri video, posibilitatea de captură de imagine sau video, sau posibiliatea de tratare de evenimente precum mișcări de mouse. Dacă cerințele aplicației depășesc ceea ce oferă acest modul, pot fi folosite „framework”-uri alternative ca Qt sau WinForms.
„Imgproc”: este modul responsabil de procesări de bază a imaginilor: aplicare de filtre, diferite transformări sau conversii de spații de culoare.
„Video”: modul responsabil de prelucrări video care includ printre altele, urmărire de obiecte sau algoritmi de procesare a fundalului.
„ObjDetect”: un modul specializat pe detecție și recunoaștere de obiecte standard.
Una dintre cele mai importante facilitãți oferite de OpenCV, care a fost folositã în realizarea estimãrii poziției capului utilizatorului, este detecția de fațã. În principal, detecțiile de fațã, ochi, gurã, nas, au la bazã un algoritm de învãțare automatã bine cunoscut, Viola Jones- „Haar Features”.
Procesul de învãțare automatã, cunoscut în englezã sub denumirea de „Machine Learning” constã în îmbunãtãțirea performanțelor unui sistem pe baza prelucrãrii unui set de date foarte mare.
Pentru folosirea bibliotecii de OpenCV este necesarã descãrcarea versiunii dorite, versiune specialã pentru dezvoltarea pe platformã Android și configurarea proiectului pentru a folosi aceastã bibliotecã. Aceastã configurarea presupune atașarea acestei librãrii proiectului folosind opțiunea „Import Module” din meniul Android Studio și setarea cã dependințã a acestui modul folosind stãrile specifice proiectului. Configurãrile de compilare sunt realizate automat dupã adãugarea dependințelor de modulul Gradle care se autosincronizeaza. În urma acestui proces, pot fi importate fișiere componente ale acestei librãrii și pot fi folosite în aplicație.
Activitatea principalã se numește „MainActivity.java” și este responsabilã atât de prelucrarea video, dar și de realizarea conexiunii prin intermediul bluetooth-ului și de trimiterea de comenzi cãtre dronã.
4.3.1 Accesarea camerei folosind OpenCV
Din punct de vedere al aplicațiilor multimedia, platforma Android oferă posibilitatea accesării și folosirii camerei telefonului mobil după dorințele fiecărui dezvoltator.
Accesul la cameră nu se face într-un mod foarte complicat și datorită limbajului de dezvoltare Java. Camera poate fi accesată în două moduri, în funcție de facilitățile dorite. În cazul în care aplicația nu presupune prelucrări ale fluxului video sau ale capturii făcute, și nu depășește facilitățile puse la dispoziție de aplicația de cameră existentă în Android se poate accesa camera prin intermediul acestei aplicații. Lansarea în execuție a camerei prin acest mod se poate face prin intermediul „MediaStore” utilizând acțiuni specifice (ACTION_IMAGE_CAPTURE, ACTION_VIDEO_CAPTURE s.a). Ulterior, există metode specifice de lansare a execuției în cadrul unei alte activități și de prelucrare a rezultatului.
În cazul în care se dorește dezvoltarea unei aplicații bazată pe cameră și pe procesări ale cadrelor primite, se folosește „Camera API” deoarece permite controlul fiecărui cadru preluat de cameră. Utilizarea acestui API necesită permisiuni declarate.
Există și alte metode de dezvoltare a aplicațiilor utilizând camera, prin intermediul unor biblioteci auxiliare.
Aplicația prezentată în această lucrare este dezvoltată utilizând Android Studio și presupune utilizarea camerei și prelucrarea fluxului video. Deoarece, pentru atingerea scopului lucrării, sunt necesare prelucrări video destul de avasate, am folosit OpenCV, iar accesarea camerei și preluarea fluxului video au fost făcute tot prin intermediul bibliotecii OpenCV. Prin implementarea interfeței specifice accesării și utilizării camerei telefonului mobil, orice cadru preluat de la cameră poate fi procesat după dorințele fiecărui dezvoltator.
Având în vedere faptul că este vorba tot de crearea unei activități, primul pas constă, ca și în cazul activității anterioare, în extinderea clasei de bază „Activity”. Deoarece această activitate este mai complexă, trebuie suprascrise, pe lângă metodă „onCreate” și metodele „onPause”, „onResume”, „onDestroy” care se vor ocupa de răspunsul aplicației în cazul în care această este părăsită temporar, dar nu închisă, în cazul în care se revine la aplicație și în cazul în care această este închisă definitiv. Setarea conținutului și configurările modului de apariție a activității sunt similare celor descrise pentru prima activitate, singurul lucru care diferă fiind fișierul de tip „layout” care se numește în acest caz „activity_main”.
Accesarea camerei prin intermediul OpenCV se face implementând interfața „CvCameraViewListener2”. Acesta interfață necesită implementarea a trei metode specifice: „onCameraViewStarted”, „onCameraViewStoped”, „onCameraFrame” și crearea unui obiect de tipul „BaseLoaderCallback”. Prima metodă din cele de mai sus este invocată atunci când pornește camera și are ca parametrii lățimea și înălțimea cadrului care va fi livrat mai departe metodei „onCameraFrame”. Cea de-a doua metodă este invocată la oprirea camerei, oprire care poate avea mai multe cauze, iar în urma apelului acesteia nu mai e livrat niciun cadru mai departe. Ultima și cea mai importantă metodă este responsabilă de preluarea fiecărui cadru furnizat sub formă unui obiect de tipul „CvCameraViewFrame” și de afișarea acestuia pe ecranul telefonului. Tipul de date returnat de această metodă este specific OpenCV, „Mat” fiind un vector n-dimensional care poate stoca valori întregi, complexe, imagini în spațiul RGB sau în GRAY, puncte sau histograme.
„BaseLoaderCallback” suprascrie o metodă care se ocupă de apeluri de tipul „callback” după ce librăria de OpenCV a fost inițializată. Inițializarea aceste librării se face prin apelul funcției „initAsync” care are ca parametrii versiunea folosită, contextul în care este folosită și obiectul de tipul „BaseLoaderCallback”. Un exemplu de apel este următorul:
OpenCVLoader.initAsync(OpenCVLoader.OPENCV_VERSION_2_4_9,this,mLoaderCallback);
Apelurile de tipul „callback” sunt tratate în funcție de această inițializare a bibliotecii. Dacă inițializarea s-a făcut cu succes, atunci camera poate fi activată prin apelul metodei „enableView”.
4.3.2 Procesarea cadrelor
Fiecare cadru poate fi accesat în interiorul metodei „onCameraFrame”. Pentru a putea fi folosit mai departe, acesta poate fi preluat într-o variabilă de tipul „Mat” prin accesarea matricei într-un anumit spațiu de culoare (nuanțe de gri sau valori RGB) și clonarea acesteia într-o nouă variabilă.
O atenție sporită trebuie acordată modului în care se face procesarea cadrelor, în vederea detecției feței. Prelucrările accesibile din OpenCV, chiar dacă au fost scrise în C++, sunt costisitoare și necesită resurse mari pentru prelucrare care nu sunt disponibile în cazul unui telefon mobil.
Din punct de vedere al memoriei disponibile pentru procesare, telefonul mobil nu este foarte ofertant, iar adăugarea de prelucrări suplimentare pe firul de execuție principal nu reprezintă o soluție foarte bună. Mai mult, în cazul procesărilor în timp real, acest lucru scade semnificativ performanțele, prelucrările apărând întârziate.
În vederea estimării mișcării capului utilizatorului a fost abordată o soluție ce presupune îmbinarea estimării mișcării pe baza detecției de față și profile, cu estimarea mișcării ca rezultat al urmăririi diferențelor dintre două cadre consecutive („optical flow”).
Cadrele sunt furnizate unul câte unul și pot fi accesate și prelucrate individual. Astfel, aplicația a fost împărțită în două părți. În prima parte, un număr de cadre este dedicat detecției de față și profile, estimându-se pe baza cadrelor anterioare (ultimele 5 cadre) mișcarea capului utilizatorului, iar în a doua parte, pe baza ultimei detecții găsite, se calculează vectorii de mișcare pe parcursul unui număr de cadre, estimându-se orientarea capului în funcție de mișcarea centroidului punctelor urmărite.
Ambele moduri de estimare sunt costisitoare deoarece presupun lucrul cu matrici de dimensiuni relativ mari (1280×786) și de aceea, am folosit pentru a implementa prima parte descrisă un fir de execuție asincron specific Android, cunoscut sub numele de AsyncTask, iar pentru partea a doua un alt fir de execuție sincronizat. Chiar și așa, cadrele necesită redimensionare pentru a menține procesul în timp real și alte prelucrări ce vor fi detaliate în continuare.
AsyncTask
Folosirea acestei clase oferă o utilizare corectă a firului de execuție principal („UI Thread”), permițând procesări executate în fundal și publicarea rezultatelor pe firul de execuție destinat intefetei.
Această clasă este concepută ca o clasă ajutătoare în procesele ce necesită prelucrări de câteva secunde. Este definit un task asincron care rulează în fundal și returnează rezultatele pe task-ul principal. Parametrii acestei clase sunt tipuri de date generice: „Params”, „Progress”, și „Result”. În cazul în care extindem această clasă trebuie furnizat tipul pentru acești trei parametrii generici și implementate cele patru metode aferente: „onPreExecute”, „doInBackground”, „onProgressUpdate” și „onPostExecute”.
Pentru a avea o performanță acceptabilă a aplicației, procesarea fiecărui cadru a fost mutată în fundal folosind o clasă ce extinde „AsyncTask”. Astfel metoda „doInBackground” primește ca parametru cadrul de pe firul de execuție principal, iar în interiorul acestei metode au loc apelurile către detectoarele folosite în estimarea poziției capului. Reprezentarea grafică a detecțiilor rezultate este realizată prin intermediul metodei „onProgressUpdate”, ce primește ca parametrii rezultatul metodei anterioare și folosind modulul OpenCV.Core desenează pe firul de execuție principal, dreptunghiuri corespunzătoare fețelor detectate.
4.3.3 Detecția de față și profile
În vederea estimării orientării capului, am folosit ca punct de plecare, detecția de față implementată în OpenCV cu ajutorul clasificatorilor în cascadă și a trăsăturilor Haar. Deși, procesarea, așa cum am explicat mai sus, a fost mutată în fundal, performanțele obținute nu sunt mulțumitoare, necesitând aplicarea unor modificări auxiliare a cadrelor în vederea aplicării detectorului de fețe.
Clasificatorii din OpenCV sunt fișiere de tipul .xml, clasificatori realizați în cascadă pe baza caracteristicilor Haar, și conțin informații ale clasificatorilor slabi identificați. Acestea sunt construite utilizând algortimul Adaboost, iar selecțiile folosite în antrenare au dimensiunea de 20×20 pixeli, atât pentru detecția de față cât și pentru ochi. Numărul de imagini folosit în antrenare nu este specificat de cei de la OpenCV, în antetul fișierelor fiind precizate informații legate de autor (Rainer Lienhart), dimensiunea folosită și informații legate de dreptul de autor. De obicei, numărul pozelor folosite în antrenare care au rata de detecție de peste 90%, este de ordinul miilor, iar performanța acestor detectoare crește odată cu creșterea volumului de date de antrenare.
O modificare importantă care schimbă considerabil rata de cadre pe secundă, este constituită de redimensionarea imaginii. La o rezoluție mai mică procesarea se face mai repede. Trebuie avut în vedere că o rezoluție prea mică ar putea afecta calitatea detecțiilor, așadar trebuie să existe un compromis. Se utilizează o detecție aplicată pe o imagine redimensionată în jurul valorilor de 320×240 pixeli. Această redimensionare se face prin intermediul modulului „Imgproc” din OpenCV, prin apelul metodei „resize”. Acestei metode îi sunt furnizați trei parametrii : imaginea sursă (în format „Mat”), imaginea destinație și dimesiunea dorită sub formă unui obiect de tipul „Size”.
Detectorul Haar trebuie aplicat pe imagini care au spațiul de culoare GRAY. Imaginea preluată este în format RGBA, dar poate fi convertită tot prin intermediul modulului de procesare de imagini „Imgproc”. Metoda prin care se realizează acest lucru este „cvColor” și primește ca intrare o imagine în spațiul RGBA, furnizând la ieșire o imagine convertită conform tipului dat ca parametru.
În urma acestor prelucrări detectorul de fețe poate fi aplicat. Pentru acest lucru este necesară încărcarea fișierului de tip „.xml” care conține clasificatorul cascadă realizat sau preluat din cele deja existențe. Aceste fișiere se găsesc în secțiunea de resurse, în directorul „raw” și pot fi accesate prin intermediul identificatorilor atașați și conținuți de fișierul „R”.
Pachetul „helpers” conține metoda care încărca fișierele specifice necesare. Această metodă încărca fișierul primit ca parametru într-un fișier temporal ca să poată fi accesat de către OpenCV. Încărcarea lui se face prin crearea unui obiect de tipul „CascadeClassifier”, care va fi apoi furnizat ca rezultat. Astfel pot fi încărcate și folosite mai multe astfel de fișiere numai prin apelul acestei metode:
cascadeClassifier = new cascadeClassifier(cascadeFile.getAbsolutePath());
Clasificatorii creați sunt furnizați ca parametrii pentru task-ul asincron. Utilizând acești clasificatori, detecția de fețe, și în general detecția obiectelor pentru care a fost antrenat clasificatorul, se realizează apelând metoda „detectMultiScale”. Această are mai mulți parametrii:
imaginea pe care se aplică detecția în spațiu de culoare GRAY și redimensionată pentru ca procesarea să fie mai rapidă;
un obiect de tipul MatOfRect care o să conțină rezultatul aplicării detectorului, acest rezultat fiind reprezentat de dreptunghiuri aferente fețelor detectate;
un factor de scalare (acesta este de tipul double) și reprezintă factorul cu care este redusă imaginea la fiecare scalare;
un întreg care specifică numărul minim de vecini pe care trebuie să îl aibă fiecare dreptunghi candidat pentru a fi reținut („minNeighbors”);
un întreg care reprezintă un indicator folosit pentru vechile tipuri de clasificatoare în cascadă;
dimensiune minimă (de tipul „Size”) care reprezintă pragul inferior de detecție;
dimensiune maximă (de tipul „Size”) care reprezintă pragul superior de detecție;
4.3.3.1 Creare clasificator pentru detecția de profile
Primul pas în crearea unui clasificator constă în pregătirea datelor de antrenare. Pentru a atinge o performanță mulțumitoare trebuie avut în vedere faptul că numărul de poze negative trebuie să fie semnificativ mai mare decât cel al pozelor pozitive ( raport minim de 2 la 1).
Există mai multe baze de date existente pe internet care oferă poze cu subiecți umani folosite pentru crearea clasificatorilor. Aceste baze de date pot fi descărcate și folosite de orice utilizatori, deoarece sunt gratis. În lucrarea prezentă, am ales să folosesc poze pozitive (poze care conțin profil stânga sau profil dreapta) ce au fost puse la dispoziție de către FotoNation, și poze negative pe care le-am descărcat clonând un spațiu de depozitare al celor de la Google [13]. Pozele negative descărcate conțin orice alte obiecte (decoruri, interioare, peisaje) mai puțin profiluri.
Am folosit ca set de intrare pentru pozele negative, un număr de 3019 poze, preluate de pe site-ul celor de la Google care oferă date pentru o demonstrație de antrenare și fișiere rezultate. Este important ca pozele de antrenare să nu fie în spațiul de culoare RGB, ci în cel GRAY pentru că informațiile referitoare la culoare vor fi ignorate. Rezoluția acestor poze este în general de 640×480 px. În figura 17 pot fi observate exemple de poze negative folosite, iar în figura 18 exemple pozitive în RGB.
Fig. 17. Imagini negativ (imagini furnizate de Google[13])
Fig. 18. Imagini pozitive (imagini furnizate de FotoNation)
Este important ca în cazul pozelor folosite formatul să fie .bmp, deoarece acesta evită apariția artefactelor care pot apărea în compresiile de tip .jpeg.
Pentru a putea fi folosite mai departe, este necesar crearea unui fișier care să conțină toate pozele negative din director și calea către acestea. Fișierul trebuie să fie de tip text (.txt) și poate fi creat cu ajutorul unei singure comenzi rulate în Command Prompt. Se navighează în directorul în care sunt aceste poze și se execută comanda „dir /b > poze_negative.txt”. Această comandă are ca rezultat un fișier numit „poze_negative.txt” care conține numele tuturor pozelor din director, și numele fișierului pe ultima linie. Acesta trebuie modificat, deoarece trebuie specificată calea relativă către poze, iar numele fișierului trebuie eliminat. Cel mai simplu mod de a realiza acest lucru este prin crearea unui alt fișier de tipul „.bat” care preia fiecare linie din cele rezultate și adaugă calea relativă pentru fiecare poză. De exemplu, putem crea fișierul „append.bat” cu sintaxa următoare:
for /F "delims=" %%j in (poze_negative.txt)
do echo.cale_relativă \%j >>poze_negative_final.txt
Se procedează în același mod și pentru pozele pozitive, creându-se în mod similar un fișier de același tip, „poze_pozitive.txt”, respectiv „poze_pozitive_final.txt”.
După crearea acestor fișiere, trebuie preluate pozele care conțin obiectul de interes (pozele care conțin profiluri, adică toate pozele pozitive) și trebuie marcată zona în care care se găsește acest obiect în imagine. Este un proces care necesită timp și răbdare, deoarece volumul de poze este mare și selecția nu poate fi automatizată. Cu toate acestea, OpenCV oferă un instrument care poate ușura procesul. Acesta se numește „objectmarker.exe” și permite utilizatorului preluarea fiecărei poze dintr-un director numit „rawdata” și marcarea singulară sau multiplă a obiectului de interes. Ca rezultat, anumite informații sunt stocate într-un fișier numit „info.txt”. Aceste informații reprezintă (în ordine): numărul de selecții făcute pe poza respectivă, coordonatele (x,y) ale punctului stânga sus al dreptunghiului de selecție, lățimea și înălțimea dreptunghiului de selecție aferente fiecărei selecții:
rawdata/153267.bmp 3 242 123 154 126 248 126 143 120 247 113 147 142
Informațiile rezultate vor fi folosite mai departe pentru a crea exemple de antrenare pe baza selecțiilor, așadar este necesară, și în acest caz, calea relativă către pozele pozitive în locul celei puse de către „objectmarker.exe” (trebuie înlocuit „rawdata” utilizând calea relativă ). Pot apărea probleme la procesările ulterioare dacă numărul de selecții salvat nu corespunde cu numărul datelor înregistrate ( se pot înregistra mai multe selecții și mai puține date salvate în fișier), de aceea este important să verificăm fișierul în urma creării și să corectăm eventualele nereguli.
Un alt utilitar din cadrul OpenCV care continuă procesul de învățare este utilitarul „create_sample.exe”. Este important să folosim utilitarele din OpenCV versiunea 2.2 doarece ultima versiune apărută nu oferă suport pentru testare pe noul format de clasificator. Acesta preia fișierul de informații rezultat și crează exemple de antrenare pe baza selecțiilor în spațiul GRAY. Selecțiile făcute nu vor fi uniforme (nu au aceeași lățime sau înălțime), dar atunci când se rulează utilitarul se specifică, pe lângă alți parametrii și dimensiunea dorită. Similar celor de mai sus, și comanda de rulare a utilitarului poate fi pusă împreună cu parametrii doriți într-un fișier „.bat”. De exemplu:
opencv_createsamples.exe -info info.txt -vec sample.vec -num 150 -w 24 -h 24 PAUSE
Specificarea înălțimii și lățimii dorite se fac utilizând „-w” și „-h” împreună cu valoarea considerată. Se recomandă ca această să fie 24×24 pixeli. Pe lângă acești doi parametrii se mai specifică și numărul de poze pozitive, dar și numele fișierului de ieșire „sample.vec”.
Modele de antrenare rezultate pot fi verificate în urma creării fișierului „sample.vec” utilizând:
opencv_createsamples.exe -vec sample.vec PAUSE
În urma verificării vom vedea imagini similare celor din figura 19 reprezentând selecții cu dimensiunea de 24×24 pixeli.
Fig. 19 Exemple de modele de antrenare
Pasul final constă în antrenarea propriu-zisă, antrenare ce se realizează prin intermediul „opencv_haartraining.exe”. Pentru a rula această antrenare trebuie să specificăm câțiva parametrii foarte importanți în acest caz:
-data <nume_director>: specifică directorul care o să conțină rezultate procesului de antrenare;
-vec <nume_fișier>: reprezintă fișierul care conține informațiile de amplasare a obiectului pentru fiecare imagine în parte (pentru fiecare imagine pozitivă);
-bg <nume_fișier>: reprezintă fișierul care conține lista cu numele pozelor negative și calea relativă a acestora;
-npos <valoare>: specifică numărul pozelor pozitive folosite în antrenare;
-nneg <valoare>: specifică numărul pozelor negative folosite în antrenare;
-nstage <valoare>: specifică numărul de etape ale procesului de învățare;
-nsplits <valoare>: reprezintă numărul de noduri de la nivelul fiecărei etape;
-mem <valoare_MB>: reprezintă memoria alocata în procesul de învățare;
-sym: specificat pentru cazurile în care obiectul de detecție este simetric;
-nonsym: specificat pentru cazurile în care obiectul de detecție nu este simetric;
-minhitrate <valoare>: reprezintă valoarea minimă care este acceptată pentru fiecare etapă (valoarea minimă de detecții pozitive);
-maxfalsealarm <valoare>: este valoare maximă de alarmă falsă acceptată pe fiecare etapă de antrenare;
-weighttrimming <valoare>: este un parametru folosit pentru algoritmii de tipul Adaboost;
-eqw: activează ponderile egale pentru poze pozitive și negative;
-mode <BASIC | CORE |ALL>: specifică tipul de trăsături Haar utilizate. În cazul „ALL” este folosit tot setul de trăsături „upright” și setul de trăsături rotite cu 45 grade;
-w <valoare>: reprezintă lățimea folosită în antrenare (de obicei este de 24 pixeli);
-h <valoare>: se specifică înălțimea folosită în antrenare ( valoare standard 24 pixeli);
-bt <DAB | RAB | LB | GAB>: se specifică tipul de algoritm folosit. Există mai multe variante ale algoritmului Ada Boost: „Discret Ada Boost”, „Real Ada Boost”, „Logic Boost” si „Gentle Ada Boost”. Valoarea standard este GAB, acesta fiind și cel mai rapid.
-err <misclass | gini | entropy>: parametru specific DAB, și reprezintă numărul de detecții prost clasificate.
-maxtreesplits <valoare>: se contruiesc arbori și nu clasificatori cascadă;
-minpos <valoare>: numărul de poze pozitive de pe fiecare cluster;
Trebuie acordată o atenție sporită acestor parametrii în vederea alegerii celor mai bune valori. În urma procesării, datele rezultate trebuie testate în vederea stabilirii performanței atinse. Pentru acest lucru se poate folosi executabilul „opencv_performance.exe”, dar pentru o versiune mai veche de OpenCV (OpenCV 2.1, nu OpenCV 2.4.10 versiunea folosită de mine). Pașii de antrenare sunt reprezentați și în figura 20.
Fig. 20. Etapele creării clasificatorului
4.3.4 Optical Flow Lucas-Kanade
Această metodă presupune determinarea punctelor ce se doresc a fi urmărite în cadrele următoare și calcularea vectorilor de mișcare aferenți.
OpenCV pune la dispoziție o metodă ce reda puncte „bune de urmarit”, puncte ce poartă numele Shi – Tomasi [31] conform celor care le-au definit. Aceste puncte sunt selectate pe baza unui prag de similitudine rezultat din analiza a două cadre succesive. Cele care au grad de similitudine mic sunt abandonate în procesul de urmărire.
Din cauza problemelor de memorie datorate prelucrărilor costisitoare, determinarea acestor puncte este făcută pe un alt fir de execuție sincronizat, rezultatele fiind întoarse printr-o metodă de „callback” înapoi pe firul de execuție principal.
Există două metode importante prin intermediul cărora se realizează determinarea și urmărirea punctelor determinate. Acestea sunt „goodFeaturesToTrack” și „calcOpticalFlowPyrLK” și au parametrii specifici. Prima dintre acestea conține următorii parametri:
Mat frame: reprezintă cadrul curent care va fi procesat pentru a determina punctele de interes;
MatOfPoint corners: este colecția de puncte rezultate în urma detecției;
int maxCorners: numărul maxim de puncte care sa fie returnate;
double qualityLevel: indicator de calitate;
double minDistance: distanța euclidiană minimă dintre punctele detectate;
Mat mask: se poate defini o zona de căutare în vederea reducerii timpului de procesare;
int blockSize: reprezintă dimensiunea blocului de pixeli ce va fi luat în considerare conform Lucas- Kanade ( de obicei, valoarea acestuia este trei);
bool useHarrisDetector: se setează true dacă se dorește utilizarea detectorului Harris;
double k: parametru specific detectorului Harris;
Un exemplu de apel al acestei metode este următorul:
Imgproc.goodFeaturesToTrack(previousFrameGray,corners, MAX_CORNERS,
QUALITY_LEVEL,MIN_DISTABCE, mask,BLOCK_SIZE,USE_HARRIS_DETECTOR,K);
În urma apelării acestei metode, rezultă colecția de puncte determinate. Aceasta va fi folosită ca intrare pentru ce-a de-a doua funcție. Trebuie avut în vedere că tipurile de date sunt diferite și utilizarea colecției de puncte rezultată nu poate fi folosită decât în urma unei conversii din MatOfPoint în MatOfPoint2f.
Metoda ce calculează punctele corespondențe în cadrul următor, are, de asemenea, mai mulți parametrii semnificativi:Mat prevImg: reprezinta cadrul anterior;
Mat currentImg: reprezintă cadrul curent;
MatOfPoint2f prevPts: repezintă punctele determinate anterior și convertite.
MatOfPoint2f nextPts: este colecția de puncte returnate de către această funcție, puncte corespondente celor determinate anterior;
MatOfByte status: este colecția asociată punctelor determinate și conține statusul pentru fiecare punct determinat;
MatOfFloat error: conține eroarea asociată fiecărui punct;
Size winSize: dimensiunea ferestrei de căutare;
int maxLevel: nivelul de piramidă folosit (0 de obicei);
TermCriteria criteria: definește limitele de terminare a detecției;
int flags: indicatori de operație;
double minEigThreshold: calculează matricea de gradient spațial;
Având și această colecție determinată, selectez punctele care au statusul „1” (pentru cele cu stautsul 1 au fost găsite corespondențe în cadrul următor), figurând noile puncte pe ecran, și actualizând punctele anterioare cu ultimele detecții.
Prin urmărirea modificărilor pe care le au punctele putem determina direcția de orientare a capului utilizatorului.
Din cauza procesării costisitoare, se pierde un numar de cadre dintre două procesări consecutive. Metoda presupunea analiza a două cadre succesive, dar în cazul Android, chiar dacă procesarea a fost mutată pe un alt fir de execuție, analizarea tuturor cadrelor ar fi scăzut mult performanțele de timp real. Având în vedere că diferența dintre cadre, în cazul meu, nu este foarte mare, pierderea unora nu afectează foarte mult performanțele.
4.4 Estimarea orientării capului utilizând detecții de față și profile
Problema determinării poziției capului este o problemă foarte complexă, pentru care nu s-a găsit încă o metodă deterministă și cu performanțe ridicate. Se încearcă însă găsirea unor metode cât mai precise de estimare a poziției capului, metodă adoptată și în această lucrare.
Pentru a estima mișcarea de „pitch” a capului, am folosit clasificatorul de detecție frontală, „haarcascade_frontalface_alt.xml” pentru a detecta, în limitele de funcționare a acestuia, față frontală. Cu toate că detecția se pierde atunci când utilizatorul întoarce capul spre stânga sau spre dreapta cu un anumit unghi, această detecție îmi oferă posibilitatea de estimare a mișcării pe baza detecției avute în ultimele zece cadre ale fluxului video.
Deoarece detecția oferă ca rezultat un dreptunghi de încadrare a feței, pentru care pot află coordonatele punctului stânga-sus, lățime și înălțime, pe baza coordonatelor 2D oferite pot estima mișcarea spre stânga sau spre dreaptă. Scopul de antrenare a celor două detectoare de profil stânga și dreapta, este acela de consolidare a estimării făcute. Dacă estimez o mișcare a utilizatorului spre stânga, urmată de o detecție de profil stânga, atunci pot spune că utilizatorul a mișcat capul spre stânga cu o mai mare siguranță decât în cazul estimării singulare.
În ceea ce privește mișcarea de „yaw” a capului, am folosit în limitele detectorului frontal, tot o estimare în funcție de ultimele zece cadre preluate.
4.5 Estimarea orientării capului utilizând „optical flow”
Această estimare se bazează pe punctele Shi-Tomasi. Nu toate punctele furnizate sunt puncte care ajută la detectarea orientării capului, de aceea trebuie făcută o selecție. Mențin numai punctele care nu s-au deplasat foarte mult între două cadre succesive și numai cele pentru care s-au găsit corespondențe. Apoi determin centroidul detecțiilor vechi și al detecțiilor noi și interpretez deplasarea pentru a putea lua o decizie de comandă.
Datorită faptului că se urmăresc puncte doar cu un anumit grad de similitudine și numai cele pentru care s-a găsit o corespondență, multe dintre acestea dispar de-a lungul procesării cadrelor. O nouă căutare are loc atunci când numărul acestora scade sub zece puncte.
4.6 Implementare modul conexiune Bluetooth
Pentru a realiza partea de control autonom, este necesar să poată fi trimise comenzi de la telefonul mobil către dronă. Acest lucru se realizează prin intermediul modulului de bluetooth, modul care presupune crearea unei conexiuni specifice.
O conexiune bluetooth este un mod de transmisie și recepție date ce nu presupune o legătură fizică între dispozitive (fie că este vorba de telefoane mobile,tablete sau de circuite electrice cu care putem interfața). Android pune la dispoziție „Bluetooth API” ca instrument de dezvoltare, capabil de scanarea și detectarea dispozitivelor care au bluetooth și sunt vizibile, capabil de crearea unei liste care să conțină dispozitivele cu care este asociat și de crearea unei conexiuni cu un alt dispozitiv.
Pentru a putea utiliza această facilitate este necesară specificarea unor permisiunii de folosire a bluetooth-ului. Aceste permisiuni se referă la acceptarea unei conexiuni, la transferul de date, dar și la dispozitivul care se ocupă de inițierea căutării și a managementului comunicației. Acest lucru se face utilizând sintaxa următoare:
<uses-permission android:name="android.permission.BLUETOOTH" />
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
Un prim pas în realizarea conexiunii este crearea unui obiect de tip „BluetoothAdapter”. Acesta nu poate lipsi din crearea conexiunii, deoarece prin intermediul lui se verifică dacă dispozitivul pe care rulează aplicația are bluetooth și tot prin intermediul lui se activează bluetooth-ul și se caută dispozitivele care sunt vizibile pentru o conectare ulterioară. Toate aceste lucruri se verifică prin intermediul unor constante definite în Android (de exemplu: ACTION_DISCOVERY_FINISHED, pentru detecția terminării etapei de căutare a dispozitivelor).
O conexiune bluetooth necesită și crearea unui „BroadcastReceiver” care este responsabil de răspunsul mesajelor de broadcast provenite de la alte aplicații sau chiar de la aplicația dezvoltată în șine. Aceste mesaje sunt numite și evenimente. La crearea unui astfel de obiect este necesară suprascrierea unei funcții, numită „onReceive”, în care va putea fi accesat fiecare mesaj primit ca parametru. Tot aici poate fi creată și o listă cu dispozitivele disponibile pentru asociere („Pairing”) și conectare, dar având în vedere faptul că aplicația urmărește conectarea cu modulul atașat dronei, nu sunt menținute toate aceste dispozitive, ci numai cel de interes, filtrarea făcându-se după numele dispozitivului. Crearea dispozitivului se face utilizând sintaxa:
BluetoothDevice device = intent.getParcelableExtra (BluetoothDevice.
EXTRA_DEVICE);
În urma creării dispozitivului, pentru conectarea propriu-zisă trebuie creat un „socket” prin intermediul căruia va fi creată conexiunea, pe baza unui identificator asociat dispozitivului. Acest „socket” este similar celui utilizat în conexiunile TCP, însă în cazul Android cel mai utilizat tip de „socket” pentru bluetooth este cel de dip RCFCOMM. Acesta este orientat pe conexiune, fiind cunoscut și sub numele de „Serial Port Pofile (SSP)”. Identificatorul unic, în cazul plăcuței bluetooth folosite, cunoscut sub numele de „SSP UUID” și are valoarea „00001101-0000-1000-8000-00805F9B34FB”.
Datele transmise sau recepționate, sunt accesate tot prin intermediul „socket”-ului creat utilizând tipuri de date specifice :”InputStream”, „OutputStream”.Astfel, conexiunea este creată și poate fi folosită în transferul sau recepționarea datelor.
4.7 Arduino IDE. ArduPilot v3.2.1
În construcția dronei am ales un autopilot al cărui soft nu necesită licență pentru utilizare și care este distribuit gratuit. Acest autopilot este APM 2.6. Una dintre cele mai importante caracteristici ale autopilotului APM 2.6 este compatibilitatea cu Arduino IDE.
Arduino IDE este un mediu de dezvoltare gratuit care permite programarea unei game variate de microcontrolere, rulând atât pe Windows, Mac OS X , dar și Linux. Prin intermediul lui putem scrie programe în C, C++ pentru microcontrollere Altmel ATMEGA8 sau ATMEGA168, de exemplu.
Softul care este pe microcontrolerul autopilotului este și el la rândul lui liber de licență și poate fi oricând modificat și rescris prin intermediul acestui IDE. Deoarece este accesibil oricărui utilizator, fiind pus la dispoziție de cei de la ArduPilot pentru descărcare gratis, poate fi modificat și actualizat conform cerințelor proiectului. Este relativ simplu de configurat, deoarece toți pașii sunt prezentați detaliat pe site-ul celor de la ArduCopter.
Un prim pas este descărcarea codului sursă. După descărcarea codului sursă și dezarhivarea acestuia, putem configura Arduino IDE. Acest lucru se face setând „Sketchbook location”, din meniul „Preferences”, să folosesca codul sursă descărcat. În urma acestui pas, în secțiunea „Sketchbook” vor fi accesibile fișierele specifice mai multor tipuri de multicoptere. Trebuie ales cel specific tipului de multicopter avut, în cazul meu ArduCopter. Toate fișierele sursă vor fi deschise de către acest mediu și vor putea fi modificate, compilate și încărcate prin intermediul USB-ului pe autopilot. O atenție sporită trebuie acordată dimensiunii softului, deoarece AMP 2.6 are un maxim de memorie funcțională de 241K. În cazul în care în urma unor modificări această dimensiune este depășită, softul nu va putea fi scris în întregime pe microcontroller și vor apărea probleme, așadar va trebui să renunțăm la module care nu sunt folositoare în aplicația noastră pentru a putea rămâne în limitele impuse. Pe lângă limita de memorie trebuie avut în vedere că scrierea se face la 57600 și trebuie verificat acest lucru în setările portului pe care este conectat ArduCopter (setări accesibile din „Device Manager”).
Ardupilot este întreagă distribuție oferită, cea compatibilă cu APM 2.6 fiind versiunea 3.2.1 ArduCopter. Cuprinde o serie de fișiere C care sunt responsabile de performanțele autopilotului. Acestea specifică toți parametrii configurabili, senzorii suportați, precum și codul aferent acestora și mai multe moduri de zbor predefinite.
Comunitatea care este responsabilă de dezvoltarea și actualizarea acestui soft este formată din 135 de contribuitori activi, cu contribuții recente, iar suportul oferit de întreagă comuniate de dezvoltatori de astfel de aplicații este de mare ajutor în rezolvarea problemelor.
4.8 Preluare date de la dronă. Interpretare mesaje MAVLink.
Drona, furnizează prin intermediul modulului de telemetrie, către modulul de bluetooth, datele de zbor specifice. Acestea sunt interceptate prin intermediul conexiunii create și sunt interpretate utilizând protocolul MAVLink.
Pentru a putea interpreta mai ușor mesajele provenite în formatul MAVLink, am folosit un o bibliotecă java, creată de mai multe persoane și care poate fi găsită și preluată gratuit de pe platformă GitHub.
Prin intermediul acestui interpretor de mesaje MAVLink, datele trimise prin bluetooth sunt preluate, din șirul de biți transmiși, într-un pachet MAVLink-„mavLinkPacket”. În cazul în care nu se face nicio filtrare a mesajelor, iar din soft-ul de pe dronă este configurat să fie trimise toate datele de zbor posibile, pachetul va conține date de la toți senzorii disponibili. Acestea pot fi vizualizate folosind metoda „unpack” pe pachetul creat și pot fi identificate în funcție de identificatorul asociat fiecăruia, conform aplicației. De exemplu:
MAVLinkPacket mavLinkPacket = mavLinkParser.mavlink_parse_char(buffer[i] & 0xFF);
mavLinkPacket.unpack()
Mesajele preluate au structura din tabelul 1:
Tabelul 1. Tipuri de mesaje MAVLink
4.8 Comanda dronă
Drona este comandată prin intermediul bluetooth-ului, utilizând ca modul intermediar „Maestro 6-Channels”. Acest modul are nevoie de trimiterea unui semnal de inițializare, așadar prima comandă care va fi trimisă prin bluetooth este comanda de inițializare a acestui modul pentru ca datele să fie trimise mai departe către AMP. Această comandă constă în trimiterea acestui semnal de intializare care este 0xAA.
În ceea ce privește trimiterea datelor prin intermediul bluetooth-ului, dar și recepționarea acestor datelor trimise de către alte dispozitive, acest lucru se realizează sub forma unui șir de biți.
În urmă inițializării, ca o confirmare fizică, ledul de pe plăcuța „Micro Maestro” trebuie să lumineze intermitent și cu o frecvență schimbată față de cea inițială. Acest modul are și un protocol special care trebuie respectat în trimiterea de comenzi, protocol numit „Mini SSC Protocol”. Conform acestuia, modulul auxiliar folosit primește o comandă sub formă unui șir de biți format din trei componente:
primul bit este standard și are valoarea 0xFF;
al doilea bit reprezintă canalul de transmisie care poate avea o valoare între 1 și 4, reprezentând valori pentru „yaw”, „pitch”, „roll” și „throttle” specifice dronei.
al treilea bit reprezintă valoarea trimisă pe canalul dorit, valoare care va fi transformată în comandă pentru motoare de către autopilot.
Motoarele dronei nu pot fi controlate independent, doar canalele putând fi controlate prin această comunicație. Ca măsură de siguranță, semnalul de inițializare pentru modulul „Micro Maestro” poate fi trimis de două ori deoarece până la acest pas se mai crează și conexiunea bluetooth și alte setări și e posibil ca semnalul să fie trimis înainte de acestea și să nu ajungă la destinație. Un exemplu de inițializare de și de comandă este următorul:
Byte[] initMaestro = {(byte) 0xAA};
btService.sendData(initMaestro);
Byte[] dataToSendSSCPotocol = {(byte)0xFF, (byte) channel, (byte) value}
btService.sendData(dataToSendSSCProtocol);
Comanda dronei necesită trimiterea continuă de astfel de comenzi, așadar acest lucru se realizează prin intermediul unui fir de execuție.
4.9 Conexiune și comandă robot ABB pentru realizarea testării.
Drona este un echipament sensibil, și de aceea este important ca implementarea să fie testată într-un mediu simulat înainte de a fi pus pe dronă. Pentru acest lucru, ce-a mai simplă rapidă soluție este interceptarea comenzilor trimise pe conexiunea bluetooth și trimiterea acestora mai departe către mediul de testare ales pentru a testa reacția avută.
Pentru a simula gradele de libertate ale capului uman, am folosit un robot numit ABB IRB 1600 care dispune de șase grade de libertate și conexiune serială. Acesta este un robot industrial care a fost construit pentru prelucrări ce necesită multă putere (10 kg), multă precizie și o viteză ridicată de prelucrare. Figura 21 prezintă acest robot, iar limitele de mișcare sunt descrise de figura 22.
Fig. 21. Robotul ABB IRB 1600 Fig. 22. Limite de mișcare.
Datorită preciziei mare pe care o pune la dispoziție, acest robot programabil, poate fi utilizat în diferite scenarii de testare și evaluare. În ceea ce privește domeniul de imagistică, poate fi folosit atât pentru achiziționare de imagini( de exemplu, achiziționare de imagini la diferite unghiuri), achiziționare video la o viteză constantă, testare aparatură sau aplicații dezvoltate sau chiar și pentru reglarea unor parametrii ai aplicațiilor.
ABB IRB este un robot capabil de a executa mișcări de translație și de rotație, furnizate de către utilizator prin intermediul unui program creat. Există chiar și posibilitatea rulării pas cu pas a unui program existent în vederea urmăririi în detaliu a execuției. Deplasarea robotului se realizează în cuante. O cuantă reprezintă o unitate de translație sau rotație. În ceea ce privește translația, o cuantă corespunde unei mișcări de translație executată pe 2cm ( dacă se dorește translatarea pe 10 centimetrii a robotului pe una din axele acestuia, X, Y, Z, valoarea furnizată va fi 5). Din punct de vedere al rotației, o cuantă reprezintă 0,5 grade, ceea ce înseamnă că pentru o deplasare de 5 grade, valoarea setată de rotație pentru axă dorită va fi 10. Translația poate fi combinată și cu mișcări de rotație dacă aplicația cere acest lucru.
În vederea interceptării comenzilor trimise pe conexiunea bluetooth este necesară utilizarea unui dispozitiv bluetooth conectat la calculator sau un calculator ce dispune de bluetooth. Am folosit un bluetooth ce poate fi atașat pe un port USB al calculatorului.
4.9.1 Creare server bluetooth
Conexiunea bluetooth realizată pe telefonul mobil este de tip client. Acesta se conectează la modul de bluetooth ce reprezintă serverul. În vederea testării utilizând robotul ABB, am creat un server utilizând Visual Studio și o bibliotecă specifică pentru aceast tip de conexiune, bibliotecă numită 32feet.net. Aceasta oferă suport pentru conexiuni de tip Bluetooth, IrDA sau Object Exchange.
Proiectul realizat în Visual Studio este de tip WindowsForms și conține o fereastră cu un buton de pornire a serverului și o zonă de informații în care sunt afișate mesajele recepționate (reprezentarea este în figura 23).
Fig. 23. Server bluetooth
Pentru a porni serverul și a aștepta conectarea clienților de tip bluetooth am creat un fir de execuție care are ca țintă („Target”) un obiect de tipul „BluetoothListener”, creat pe baza identificatorului unic al dispozitivului bluetooth (UUID). Acesta este pornit și așteaptă crearea conexiunii bluetooth cu dispozitivul client. În urma realizării conexiunii, pot fi trimise comenzi codificate sub forma unui șir de biți. Este important ca UUID-ul specificat să fie același atât în aplicația Android cât și în cea Desktop. Sintaxa de creare a conexiunii este următoarea:
Thread bluetoothServerThread = new Thread(new ThreadStart(ServerConnectThread)); bluetoothServerThread.Start();
…
Guid btUuid = new Guid("00001105-0000-1000-8000-00805F9B34FB");
BluetoothListener btListener = new BluetoothListener(btUuid);
btListener.Start();
BluetoothClient conn = btListener.AcceptBluetoothClient();
Comenzile trimise din aplicația Android, pe baza prelucrărilor fluxului video, sunt comenzi de rotație sau translație. Acestea conțin informații precum direcția de translatare (dreapta, stânga, sus sau jos) pentru fiecare axă și amplitudinea translatării dorită. În cazul mișcării de rotație, comanda presupune setarea direcției și amplitudinii.
Pentru a putea fi interpretate mai ușor de către programul de pe ABB, am codificat direcțiile de deplasate dorite. Astfel există două axe pe care se poate face translație, iar pentru fiecare axă există două posibilități: „0” reprezentând dreapta sau sus, în funcție de axă folosită și „2” ce reprezintă stânga sau jos în mod analog. Aceeași codificare se menține și în cazul mișcării de rotație indicând direcția de rotație stânga sau dreapta. Comenzile au următoarea sintaxă:
MakeTrans3DCommand(byte ox, byte oy, byte oz, byte Ax, byte Ay, byte Az);
MakeRotCommand(byte dir, byte amp);
Aceste comenzi sunt preluate prin intermediul conexiunii și sunt trimise mai departe pe portul serial pe care este conectat robotul. Setarea conexiunii pe serială se face cu ajutorul unui obiect de tip SerialPort. Pentru acesta trebuie setat numele portului, timpul de expirare în cazul citirii și scrierii. Sintaxa este următoarea:
serialPort = new SerialPort();
serialPort.PortName = "COM8";
serialPort.ReadTimeout = 50000;
serialPort.WriteTimeout = 5000;
serialPort.Open();
Trimiterea mesajului recepționat pe serială se face utilizând metoda „write” ce primește ca parametru mesajul sub forma unui șir de biți, poziția de început și lungimea mesajului transmis:
serialPort.Write(received, 0, received.Length);
ABB IRB preia mesajele transmise prin intermediul unui program ce ruleazã pe acesta și executã mișcãrile conform comenzilor trimise, executând mișcãri în direcțiile indicate și cu amplitudinea specificatã.
5. Utilizarea și evaluarea aplicației
5.1 Instalare aplicație Android
În ceea ce privește instalarea aplicației pe dispozitivele mobile ce rulează Android, acest lucru se poate face în două feluri. În cazul în care sursele sunt disponibile și utilizatorul are mediul de dezvoltare Android Studio instalat și opțiunile de dezvltator activate pe telefonul mobil, instalarea se realizează prin rularea aplicației pe acest dispozitiv. În caz contrar, atunci când utilizatorul nu are acces la sursele aplicației și dispune numai de fișierul „.apk”, aplicația va fi instalată prin rularea acestui fișier.
APK este aconimul de la „Android application package file” și reprezintă extensia fișierelor utilizate pentru distribuirea și instalarea aplicațiilor pe sisteme ce rulează Android. Toate aplicațiile care au ca țintă dispozitive mobile ce au ca sistem de operare Android, au această extensie. Astfel, toată aplicația este livrată ca un produs finit sub forma unui singur fișier. Aceste fișiere sunt generate în urma compilării de către SDK-uri („Software Development Kit”).
Indiferent de modul în care se procedează pentru instalarea aplicației, aceasta mai necesită un program ajutător instalat. Deoarece în implementare este folosit OpenCV, utilizatori vor trebui să aibă instalat pe telefon „OpenCV Manager” pentru a rula aplicația.
În urma procesului descris mai sus aplicația va putea fi rulată pe telefonul mobil însă, este nevoie și de partea fizică a acesteia, adică de dronă. Cadrul și motoarele dronei construite pot varia, dar partea de arhitectură a comunicației va trebui menținută așa cum a fost descrisă în capitolul „Arhitectura aplicatiei”, modulele auxiliare folosite pentru schimbarea modului de control al dronei fiind foarte importante.
Întrucât comunicația între aplicația mobilă și dronă se realizează prin intermediul conexiunii bluetooth, trebuie ca telefonul și modulul de bluetooth folosit să fie asociate („Pair”) și bluetooth-ul telefonului să fie activ și vizibil.
Aplicația a fost gândită să ofere un mod autonom de control. Așadar, cu telefonul atașat dronei pe gimbal, drona ar fi trebuit ridicată la înălțimea utilizatorului folosind telecomandă, iar apoi menținută la această altitudine și schimbată pe modul de control autonom prin aplicația creată. Pentru a realiza acest lucru au fost încercate două soluții: o soluție ce presupunea utilizarea unui senzor optic pentru menținerea altitudinii la un nivel specificat într-un mediu închis (o încăpere) și o soluție ce presupunea controlul autonom în spațiu deschis bazat pe GPS.
Prima soluție propusă nu a avut succes deoarece necesită implementarea unui mod de zbor care să folosească senzorul ales, ArduCopter neanunțând oficial implementarea acestuia. Deși senzorul este recunoscut și testându-l, cu un program extern, am putut prelua date de la acesta, scrierea unui nou mod de zbor pentru dronă ar fi fost consumatoare de timp, ar fi presupus foarte multe schimbări în softul autopilotului, putând constitui chiar subiectul unei noi lucrări.
Cea de-a doua soluție nu a fost viabilă deoarece eroarea GPS-ului, în urma unor teste făcute într-un spațiu deschis, era foarte mare și viteza de transmisie a datelor de poziționare foarte mică fiind foarte greu de stabilizat într-un punct prin acesta metodă.
5.2 Evaluare aplicație
Aplicația dezvoltată pe Android execută procesări în timp real asupra cadrelor preluate de la cameră. Deoarece aceste prelucrări sunt destul de consumatoare și telefonul mobil impune anumite limitări în ceea ce privește puterea de procesare și memoria, performanțele acestei aplicații nu sunt foarte ridicate. Dacă nu se omite niciun cadru din prelucrare, performanță acestei aplicații este în jurul a cinci fps-uri, rularea fiind fluență, iar în cazul în care se omit cadre din prelucrare, performantă crește până la opt-zece fps-uri, dar momentul în care se prelucrează este vizibil și de către utilizator.
Implementarea părții de detecție de față și de profil se bazează pe clasificatorii în cascadă creați cu ajutorul caracteristicilor Haar. În timpul antrenării, sunt furnizate informații referitoare la parametrii folosiți, numărul de poze pozitive și câte dintre acestea au fost consumate pe fiecare etapă, numărul de poze negative și gradul de acceptare al acestora raportat la fiecare etapă, timpul de calcul, timpul total de antrenare și un tabel care conține numărul de caracteristici utilizate (N), iar pentru fiecare caracteristică valoarea dă „hit rate” (HR) și „false alarm” (FA). Rezultate ale antrenării clasificatorului pot fi găsite în talelul 2 :
Tabelul 2. Rezultate furnizate în procesul de antrenare.
Un alt aspect important, care ajută la determinarea numărului de etape necesar constă în urmărirea gradului de acceptanță (procentul de acceptare al pozelor negative- NEG acceptanceRatio) rezultat la fiecare etapă. Deși, s-ar părea că acesta trebuie să fie cât mai mic, un grad de acceptare de tipul 4.38406e-005 nu înseamnă neapărat performanțe mai bune. Pentru un astfel de grad de acceptare pentru pozele negative, clasificatorul poate deveni „supra antrenat” („overtrained”) și poate să nu detecteze obiectele de interes din această cauză, având o performanță foarte scăzută. De aceea este bine ca antrenarea să se oprească atunci când gradul de acceptanță ajunge în jurul valorii de 0.0001. Rezultatele prezente în tabelul de mai sus sunt cele mai bune rezultate, respectând observațiile făcute mai sus.
Antrenarea unui astfel de clasificator a fost prezentată anterior în capitolul „Implementarea aplicatiei”, însă OpenCV oferă și un instrument de testare a performanțelor care redă informații despre numărul de detecții pozitive, fals negative sau fals pozitive și informații specifice graficului ROC (rată de detecții pozitive și de detecții negative). Pentru evaluarea performanțelor clasificatorului în cascadă creat cu ajutorul caracateristicilor Haar trebuie alcătuit un set de date similar celui de antrenare care conține amplasarea profilului în fiecare poză.
Aplicația a fost dezvoltată utilizând OpenCV 2.4.10, însă în această versiune partea de antrenare clasificatori nu a mai avut același suport din partea dezvoltatorilor. Clasificatorul poate fi creat și în această structură, dar diferă ca și structură și nu poate fi testat din această cauza utilizând „opencv_performance.exe”. Așadar am antrenat un nou clasificator cu aceleași date, dar utilizând OpenCV 2.2, versiunea care oferă suport și pentru partea de testare. Pentru a utiliza executabilul de testare a performanței trebuie să furnizam clasificatorul creat, fișierul cu profiluri marcate, dimensiunile care au fost folosite în antrenare (-w -h) și dimensiunea pentru graficul ROC (standard este 40 ).
opencv_performance.exe -data clasifier -info testPerformance.txt -w 24 -h 24 -rs 40 >> testResult.txt
În vederea urmăririi performanței clasificatorului am creat trei clasificatori cu 100, 150 și respectiv 300 de poze pozitive, iar rezultatele sunt prezentate în continuare (testarea a fost făcută pe cele 300 de selecții).
La început am antrenat un clasificator cu numai 100 de poze pozitive, având numai șase etape de antrenare deoarece în a șasea etapă de antrenare s-a atins valoarea de alarmă falsă calculată în funcție de numărul de etape și numărul de poze furnizate. Rezultatele din urma testării sunt în formatul din tabelul 3:
Tabel 3. Rezultate obținute în urma rulării opencv_performance.exe.
Numărul total de clasificatori folosiți în testare, în cele șase etape, a fost de 29 de clasificatori „slabi”, iar timpul total necesar rulării a fost de 6.363 secunde. În urma acestor rezultate se observă performanță scăzută a clasificatorului rezultat. Pe lângă datele oferite, „opencv_performance.exe” furnizează și datele necesare reprezentării curbei ROC („Receive Operating Characteristic Curve”). Acest grafic evidențiază dependența dintre rata de detecții pozitive („true positive”) și rata de detecții fals pozitive („false positive”). Pentru acest scenariu de test, rezultatele pot fi urmărite în tabelul 4, iar graficul corespunzător în figura 24.
Tabelul 4. Date curba ROC, primul scenariu de test.
Fig. 24. Reprezentare ROC, primul scenariu de test (100 de poze de antrenare).
Performanțele clasificatorului pot fi calculate și utilizându-ne de numărul de detecții pozitive (TP), numărul de detecții fals negative (FN), numărul de detecții false pozitive (FP) și de numărul de detecții negative (TN),conform articolului [29]. Astfel putem calcula:
Sensibilitate (numită și rată de detecții pozitive sau „true positive rate”, „hit rate”, „recall” în engleză): ;
Specificitate (numită și „true negative rate”): ;
Precizie („positive predictive value”): ;
Confuzie („negative predictive value”): ;
Rata de fals pozitive („false positive rate”): ;
Rata de fals negative („false negative rate”): ;
Rata de descoperiri false („false discovery rate”): ;
În cazul scenariului prezentat mai sus avem : TP = 44, FN = 256, FP = 186. În acest caz obținem performanțe slabe, sensibilitatea fiind scazută (14,66%) si precizia la fel (19,13%) și în consecință rate foarte mari pentru fals negative și detecții false (FNR = 85,34%, respectiv FDR = 80,87%).
Având în vedere performanțele scăzute, numărul de poze a fost crescut la 150 și ca urmare, performanțele au crescut. Valorile înregistrate au fost: TP = 76, FN = 224, FP = 77; Rezultatele pe baza cărora s-au facut calculele sunt în tabelul 5, iar graficul corespunzător este figura 25.
Tabelul 5. Date curba ROC, al doilea scenariu de test.
Fig. 25. Reprezentare ROC, al doilea scenariu de test (150 de poze de antrenare).
În ceea ce privește sensibilitatea și precizia, se observă o îmbunătățire a procentelor: TPR = 25.33% și PPV = 49.67%.
În cazul celor 150 de poze, se observă o creștere ușoară a performanțelor față de cazul precedent, dar valorile sunt încă foarte scăzute. Privind cele două scenarii create, putem observă că o creștere a numărului de poze are un efect pozitiv așa cum ne-am fi așteptat în cazul algoritmilor de învățare automată. Având acest lucru în vedere, ultimul scenariu de test conține 300 de poze pentru antrenare. Secvența de antrenare folosită conține următorii parametrii:
>opencv_haartraining.exe -data classifier_300 -vec sample_300.vec -bg poze_negative_final.txt -npos 300 -nneg 3019 -nstages 15 -nsplits 2 -mem 8192 -nonsym -minhitrate 0.999 –maxfalsealarm 0.5 -weighttrimming 0.95 -eqw -mode ALL -w 24 -h 24 -maxtreesplits 0 -minpos 300
Limită de alarmă falsă a fost atinsă în etapa a 11-a, rata de acceptanță pentru pozele negative scăzând până la o valoare de 8.37504e-006. Odată cu trecerea etapelor, numărul de caracteristici folosite crește, ajungând, de exemplu, în etapa a zecea la valoarea de 20. Aplicând același test pe clasificatorul rezultat obținem: TP = 255, FN = 45 și FP = 61. Conform acestor date sensibilitatea clasificatorului devine TPR = 85%, iar precizia acestuia ia valoarea PPV = 80,69%. Se observă o creștere semnificativă a preciziei clasificatorului, rata de detecții fals negative scăzând considerabil FNR = 15%, FDR = 19,31%. Aceste performanțe pot fi observate și în reprezentarea din figura 26, pe baza tabelului 6.
Tabelul 6. Date curba ROC, ultimul scenariu de test
Fig. 26. Reprezentarea ROC, ultimul scenariu de test (300 de poze de antenare).
Detecțiile rezultate în urma procesării sunt figurate pe ecran prin intermediul unor dreptunghiuri de încadrare (figura 27). În ceea ce privește detecția de față frontală implementată de cei de la OpenCV, se observă faptul că aceasta poate detecta fețe până la aproximativ un metru distanță față de cameră, acceptând și un anumit unghi de ”yaw” și ”pitch”. Figura 28 prezintă detecții de față și ochi până la distanța aproximativă de un metru, iar figurile 29 si 30 prezintă unghiurile de yaw și pitch suportate de detecție.
Fig. 27. Reprezentare detecție față frontală și ochi
Fig. 28. Detecția frontală și detecția de ochi la diferite distanțe
Fig. 29. Detecția de față – unghi de yaw
Fig. 30. Detecția de față – unghi de pitch
Datorită performanțelor ridicate ale acestor detecții, în mediul de test sunt puține cazurile în care se înregistrează detecții false, dar nu sunt inexistente.
În cazul detectoarelor antrenate apar detecții false datorită preciziei relativ scăzute (aproximativ 80% precizie), dar numărul acestora este redus. Detecția de profil este reprezentată tot prin intermediul unor dreptunghiuri, de data aceasta de culoare verde pentru a se face distincția între detecțiile rezultate. Un exemplu de detecție de profil dreapta și un exemplu de detecție de profil stânga sunt reprezentate în figura 31, respectiv 32, iar o detecție eronată apare în figura 33.
Fig. 31. Detecție profil stânga Fig. 32. Detecție profil dreapta
Fig. 33. Detecție profil eronată
Toate aceste detecții sunt rezultatul unei procesări ce are loc în timp real, performanța înregistrată fiind situată în intervalul 5-6 fps (frame per second).
Există și cazuri în cadrele pot fi suprapuse, din cauza faptului că se lucrează cu un fir de execuție asincron. În aceste cazuri, deși detecția se face corect, reprezentarea detecțiilor poate fi incomplet realizată în ceea ce privește percepția utilizatorului. Un astfel de caz este reprezentat în figura 34. Aceste cazuri nu reprezintă o problemă pentru control deoarece detecția s-a realizat cu succes și numai partea de desenare este incompletă.
Fig. 34. Desenare incompletă a detecției.
În ceea ce privește partea de urmărire de puncte, aceasta are doua etape. Prima etapă constă in căutarea punctelor de interes în aria ultimei detecții, iar a doua etapă constă în urmărirea punctelor în cadrele succesive. Din cauza procesării greoaie, unele cadre se pierd între două procesări consecutive pentru a se menține aplicația să ruleze în timp real, așadar, de la un cadru la altul dispar și din punctele de interes, necesitând recăutarea lor. Figura 35 prezintă, în ordine, ultima detecție de față avută, punctele detectate inițial (figurate cu roșu) și în cadrul următor (figurate cu verde), centroidul punctelor ințiale (figurat cu alb), centroidul punctelor următoare (figurat cu albastru) și câteva cadre de umărire.
Fig. 35. Detectarea punctelor de interes si urmărirea lor
În cazul în care fața nu se mișcă puntele detectate vor fi suprapuse peste cele vechi, iar în cazul în care se produce o mișcare se observă decalarea lor, decalare figurată și prin linia roșie trasată vizibilă în figura 35. Decizia de comandă se ia pe baza deplasărilor detectate. Rata de fps-uri înregistrată în acest caz este în jurul valori de 7-8 fps-uri datorită restricționării ariei de căutare inițială.
Testarea utilizând robotul, pentru a vedea o reacție a algoritmului înaintea testării pe dronă s-a realizat utilizând camera frontală a telefonului mobil (la fel ca și în cazul imaginilor de mai sus care au fost preluate cu telefonul montat pe robot), și un calculator responsabil de rularea programului ce are rol de server de bluetooth și e responsabil și de interpretarea si transmiterea comenzilor mai departe pe portul serial. Ca reacție a comenzilor, robotul execută mișcări de rotație și translație specifice intrepretării.
Transmisia comenzilor din telefonul mobil către bluetooth și apoi către robot se face aproape instantaneu, singurul lucru care necesită timp fiind execuția comenzii trimise. În urma trimiterii unei comenzi pe serială se așteaptă răspuns din partea robotului la finalizarea comenzii. Mișcarea propriu-zisă s-a realizat folosind cuante mici așadar timpul de execuție nu a afectat procesul de trimitere a comenzilor.
Testarea realizată cu acest robot are rol și de îmbunătățire a algoritmului în vederea stabilirii limitelor care dau cele mai bune rezultate, fiind, așadar o etapă indispensabilă până la execuția pe dronă.
6. Concluzii și dezvoltări ulterioare
6.1 Concluzii
În vederea realizării proiectului prezentat în această lucrare, există mai multe puncte cheie care trebuie tratate cu implicare și simt de răspundere.
Construcția dronei, după cum am văzut, necesită cunoașterea cerințelor aplicației pentru a putea stabili elementele fizice necesare, dar și autopilotul care ne oferă cele mai multe facilități utile în atingerea scopului. Astfel am ales fibra de carbon pentru construcție, un cadru solid în configurație ”X”, motoare, elici și baterie care pot susține o greutate auxiliară de până la 1kg timp de 15 minute în aer, senzori specifici (senzor optic, sonar) și autopilotul APM 2.6 care oferă libertate de programare fiind distribuit gratis de producători.
În ceea ce privește partea de control pe baza telefonului mobil, a fost necesară schimbarea de pe modul de control manul, pe modul de control din telefon, schimbare ce a necesitat construirea unui circuit auxiliar. Acesta realizează transmiterea comenzii de la telefon, prin intermediul bluetooth-ului către autopilotul dronei, fiind un circuit indispensabil.
Accesarea datelor de zbor trimise de dronă prin telemetrie și bluetooth către telefon a necesitat rescrierea soft-ului de pe autopilot cu modificările specifice prin intermediul mediului de dezvoltare Arduino IDE, un alt aspect care a contribuit la alegerea autopilotului prezentat. Problema stabilizării acesteia într-un spațiu închis, lipsit de prezenta sateliților GPS este o provocare pentru foarte mulți dezvoltatori.
Un alt punct cheie în această aplicație este reprezentat de aplicația Android realizată. Am ales această platformă de dezvoltare datorită faptului că telefonul poate fi cărat cu ușurință de către dronă și îmi permite prelucrarea fluxului video achiziționat în timp real, realizarea conexiunii bluetooth, achiziționarea datelor de zbor preluate de la autpilot și trimiterea comenzilor specifice prelucrării.
Partea de algoritmică constă în folosirea unor tehnici avansate de procesare în timp real utilizând unul dintre cei mai cunoscuți și performanți algoritmi de detecție existenți, algoritm dezvoltat de Viola-Jones. Se remarcă necesitatea existenței unui set de date foarte mare și complex, așa cum am evidențiat în această lucrare, pentru atingerea unor performanțe ridicate de detecție. De asemenea, antrenarea clasificatorilor specifici acestui algoritm necesită cunoașterea parametrilor de antrenare și executarea mai multor teste în vederea ajustării acestora sau evitării situațiilor în care clasificatorul poate ajunge să fie supra-antrenat și să nu mai recunoască obiectul în cauză. În urma mai multor teste precizia de detecție rezultată a fost de aproximativ 80%.
Un lucru care nu trebuie neglijat atunci când lucrăm pe platforma Android este managementul de memorie. Telefoanele mobile nu dispun de foarte multă memorie de procesare, spre deosebire de calculatoare și de aceea este important să ținem cont de acest lucru în dezvoltarea aplicației. Procesarea cadrelor achiziționate la rezoluția standard a camerei este costisitoare și ca timp și ca resurse, iar pentru a menține caracterul de procesare în timp real trebuie făcute mai multe ajustări. Am folosit pentru realizarea detecției cadrul redimensionat în jurul valorii de 320×240, în spațiul de culoare GRAY pentru că pe o astfel de dimensiune detecția nu este afectată, iar procesarea este mai rapidă (în jurul valorii de 5 fps). Nici pentru partea de urmărire nu am folosit întreaga imagine în determinarea punctelor, folosindu-mă de ultima detecție de față pe care am avut-o, fapt pentru care și alternez etapa de detecție cu cea de urmărire. Un compromis în ceea ce privește urmărirea constă în pierderea cadrelor ce sunt achiziționate în timpul procesării, fapt pentru care nu am obținut performanțele dorite pentru această parte, deși viteza de rulare este acceptabilă (8 fps).
Partea de testare a aplicației înaintea creării ansamblului final am realizat-o utilizând robotul ABB IRB 1600, robot care are șase grade de libertate. Acesta are scopul de a prelua comenzile furnizate, prin intermediul unei conexiuni seriale, și de a realiza mișcarea dorită. Astfel am testat mișcări de translație pe axele specifice, dar și mișcări de rotație utilizând un pas de incrementare mic.
6.2 Dezvoltări ulterioare
Domeniul specific acestei lucrări este un domeniu foarte vast. Dronele au devenit din ce în ce mai folosite apărând moduri cât mai variate de control, care să îi ofere cât mai multă libertate utilizatorului.
Pentru a obține performanțe cât mai bune este necesară dezvoltarea unei metode avansate de stabilizare a dronei atât în interiorul unei încăperi, cât și în exterior deoarece GPS-ul poate să nu funcționeze uneori din lipsa detectării sateliților. Poate utilizarea unui număr mai mare de senzori ar putea îmbunătății zborul dronei.
Întrucât autopilotul ales oferă posibilitatea dezvoltării unui nou mod de zbor, ar putea fi creat un mod special pentru acest tip de control care să nu mai implice comutarea manuală de pe modul de control manual pe modul de control automat.
În ceea ce privește partea de algoritmică o estimare ce ar include deteminarea unghiurilor de roll, pitch, și yaw ar putea fi un real avantaj, dar acest lucru include și o parte de cercetare în domeniu și nu numai de dezvoltare.
7. Bibliografie
Alberto Albiol Colomer, Video indexing using multimodal information, 4 Octombrie, 2000. Documentație internet – http://gpiserver.dcom.upv.es/publications /pdf/thesis-proposal.pdf. Accesat iunie: 2015
Android developpers. Documentație internet – https://developer.android .com/training /index.html. Accesat iunie: 2015.
Bernhard Fröba, Christian Külbeck, Real-time face detection using edge-orientation matching, 17 august 2001. Documentatie internet – http://link.springer.com /chapter/10.10 07%2F3-540-45344-X_12. Accesat iunie: 2015
Bruce D. Lucas, Generalized image matching by the method of differences, Computer Science Departament Carnegi- Mellon University Pittsburg, Pennsylvania 1213, Iulie 1984. Documentație internet – http://www.ri.cmu.edu/pub_files/pub4/lucas_bruce_1984_1/ lucas_bruce_d_1984_1.pdf .Accesat iunie: 2015
D. Brown, I. Craw, and J. Lewthwaite. A SOM based approach to skin detection with application in real time systems. In Christopher J. Taylor Timothy F. Cootes, editor, Proceedings of the British Machine Vision Conference 2001, BMVC 2001,2001. Documentație internet – http://www-2.dc.uba.ar/materias/rn/aplicacio nes/Kohonen/2000 134.pdf. Accesat iunie: 2015.
Daniel Lélis Baggio,Shervin Emami, Mastering OpenCV with prectical computer vision projects, Decembrie 2012, ISBN 978-1-84951-782-9. Documentație internet – http://image2measure.net/files/Mastering_OpenCV.pdf Accesat iunie: 2015
7.Documentatie ElecFreaks. Ultrasonic ranging module HC-SR04.Documentație internet – http://www. micropik.com /PDF/HCSR04.pdf. Accesat iunie: 2015.
Documentatie InvenSense. MPU-6000 and MPU – 6050 Product specification revision 3.4. Documentatie internet – http://www.festo-didactic.com/download.php? name=RobotinoGyroscopeProductSpecification.pdf&c_id=1100&file=robotinogyroscopeproductspecification.pdf. Accesat iunie: 2015.
Documentatie Measurement Specialties. MS5611-01BA03 Barometric pressure sensor, with stanless steel cap. Documentație internet – http://www.meas-spec.com/ downloads/MS5611-01BA03.pdf. Accesat iunie: 2015.
Erik Murphy-Chutorian, Mohan Manubhai Trivedi, Head pose estimation in computer vision: a survey. Documentație internet -http://people.ict.usc.edu/~ gratch/CSCI534/Head%20Pose %20 estimation.pdf. Accesat iunie: 2015.
Henry. A. Rowley, S. Baluja, and T. Kanade. Neural network-based face detection. IEEE Trans. on Pattern Analysis and Machine Intelligenc,Volume 20 Issue 1 , Ianuarie 1998, pag. 23-38, IEEE Computer Society Washington, DC, USA.
Informatii ADNS3080, Optical flow sensor horizontal position for APM2.5 flight control board. Documentatie internet – http://www.aliexpress.com /item/ADNS3080-Optical-Flow-Sensor-Horizontal-Position-for-APM2-5-Flight-Control-board/ 1404445315. html. Accesat: 2015.
Informații antrenare clasificator Haar. Informații internet – https://code. google. com/p/tutorial-haartraining/. Accesat iunie: 2015.
Informații despre autopilot. APM 2.5 and 2.6 Overview. Documentație internet -http://copter.ardupilot.com/wiki/common-autopilots/common-apm25-and-26-verview/. Accesat iunie: 2015.
Informații despre drone. Documentație internet – http://www.theuav.com /index.html . Accesat iunie: 2015.
Jure KovaE, Peter Peer, Franc Solina, Human Skin Colour Clustering for Face Detection. Documentație internet – http://ieeexplore.ieee.org/stamp/stamp.jsp? tp=&arnumber=1248169&tag=1. Accesat iunie: 2015
Manual de utilizare, HC Serial Bluetooth Products. Documentatie internet – http://www.tec.reutlingen-university.de/uploads/media/DatenblattHC-05_BT-Modul.pdf. Accesat iunie: 2015;
Jure KovaE, Peter Peer, Franc Solina, Human Skin Colour Clustering for Face Detection. Documentație internet – http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=& arnumber=1248169&tag=1. Accesat iunie: 2015
M. J. Jones and J. M. Rehg. Statistical color models with application to skin detection. International Journal of Computer Vision, 46(1):81–96, January 2002. Documentație internet – http://www.cc.gatech.edu/~rehg/Papers/SkinDetect-IJCV.pdf. Accesat iunie: 2015.
Oliver Jesorsky, Klaus J. Kirchberg, Robert W. Frischholz, Robust face detection using Hausdorff Distanc, Iunie 2001. Documentație internet – https://facedetection.com/wp-content/uploads/AVBPA01BioID.pdf. Accesat iunie: 2015
Parrot AR. Documentație internet – http://ardrone2.parrot.com/ardrone-2/specifi cations/. Accesat iunie: 2015
Paul Viola, Michael J. Jones, Robust real-time face detection, 2004. Documentatie internet – http://www.vision.caltech.edu/html-files/EE148-2005-Spring/pprs/viola04 ijcv.pdf. Accesat iunie: 2015
Paul Viola, Michael J. Jones, Robust real –time object detection, 13 Iulie, 2001. Documentatie internet – https://www.cs.cmu.edu/~efros/courses/LBMV07/ Papers/viola-IJCV-01.pdf. Accesat iunie: 2015
Phenox2. Documentație internet – https://www.kickstarter.com/projects/20404 41468/phenox-2-a-programmable-drone-and-platform . Accesat iunie: 2015
Pololu Corporation 2001-2004, Pololu Maestro Servo Controller User’s Guide. Documentatie internet – https://www.pololu.com/docs/pdf/0J40/maestro.pdf. Accesat iunie:2015
Pololu Corporation 2001-2015, Pololu RC Switch User’s Guide. Documentație internet – https://www.pololu.com/docs/pdf/0J60/pololu_rc_switch.pdf. Accesat iunie: 2015
Shyam Balasubramanian, MavLink tutorial for absolute dummies( Part- I). Documentație internet-http://api.ning.com/files/i*tFWQTF2R*7Mmw7hksAU9IA BKNDO9pguOiSOCfvi2znk1tXhur0Bt00jTOldFvobzg3*lDcgChG26QaHZpzEcISM5/MAVLINK_FOR _DUMMIES Part1_v.1.1.pdf. Accesat iunie: 2015
Tomaso Poggio and Kah-Key Sung. Example-based learning for view-based human face detection. IEEE Trans. on Pattern Analysis and Machine Intelligence, 1998. Documentație internet – http://www.vision.caltech.edu/ CNS179/papers/Poggio98.pdf. Accesat iunie: 2015
Thomasi G. Tape, MD, Interpreting diagnostic tests, University of Nebraska Medical Center. Documentație internet – http://gim.unmc.edu/dxtests/Default.htm. Accesat iunie: 2015
Tomasi Carlo, Jianbo Shi, Good features to track, IEEE Conference on Computer Vision and Pattern Recognition (CVPR94) Seatle, Iunie 1994. Documentație internet – http://www.ai.mit.edu/courses/6.891/handouts/shi94 good.pdf. Accesat iunie: 2015
Tutorial Opencv. Optical flow. Documentație internet – http://docs.opencv. org/master/d7/d8b/tutorial_py_lucas_kanade.html. Accesat iunie: 2015.
Yoav Freund, Robert E. Schapire, A decision – theoretic generalization of on-line learning and an application to boosting, 19 Decembrie 1996. Documentatie internet – http://www.face-rec.org/algorithms/Boosting-Ensemble/decision-theore ticgeneralization.pdf. Accesat iunie: 2015
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Controlul Unei Drone pe Baza Estimarii Orientarii Capului Utilizatorului (ID: 162244)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.