Interacțiunea Multimodală Om-Robot Umanoid ȊNDRUMĂTOR ABSOLVENT PROF. DR. ING. – DR. SC. NAT. CĂTĂLIN BUIU ANDREI-OVIDIU MOCANU BUCUREȘTI 2018… [302843]

[anonimizat]

ȊNDRUMĂTOR ABSOLVENT: [anonimizat]. – DR. SC. NAT. [anonimizat] 2018

[anonimizat] ([anonimizat], [anonimizat]) [anonimizat], subiect ce precede însăși apariția roboților. [anonimizat]-[anonimizat], [anonimizat], [anonimizat]-computer cât și stiințe sociale (sociologie, psihologie, antropologie ,economie). [anonimizat] a perfecționa și aduce cât mai aproape comportamentul robotului de cel al unui interlocutor uman.

Cercetarea în domeniul HRI prevede numeroase provocări în ceea ce privește natura interacțiunii și comportamentul social dintre robot și om.

Din totdeauna oamenii au avut o [anonimizat]. [anonimizat], ca exemplu avem “androizi” [anonimizat], XVII-[anonimizat], unde acești predecesori ai roboților moderni simulau diferite activități umane precum cântatul la trompetă (realizat din punct de vedere mecanic utilizând roți dințate și mecanisme de ceas). Lucrările [1] și [2] conțin o cronologie a [anonimizat] “robotul” lui Leonardo da Vinci (1495), robotul ce cânta la trompetă proiectat de Friedrich Kaufmann (1810) [anonimizat], [anonimizat].

[anonimizat], [anonimizat]. Prin multimodal se ințelege utilizarea mai multor sisteme de tip intrare/ieșire pentru a [anonimizat], [anonimizat], recunoaștere a [anonimizat], [anonimizat].

Capitolul 2 [anonimizat], a istoriei acesteia, a provocărilor și tendințelor de evoluție.

[anonimizat] – V5 produs de compania Aldebaran Robotics (SoftBank Group), [anonimizat], [anonimizat].

Figura 1.1. – Robotul NAO din laboratorul 504

Robotul NAO și specificațiile sale sunt descrise în capitolul 3, de asemenea în cadrul aceluiași capitol este menționat și motivul utilizării unui astfel de robot în cadrul interacțiunii propuse.

Realizarea practică constă dintr-un meniu dezvoltat în pygame și o serie de scripturi Python care conțin aplicații ce pot fi utilizate de către NAO în cadrul interacțiunii propuse, precum: citirea unei partituri muzicale aflate în format digital și interpretarea acesteia pe note (solfegiu), interpretarea partiturii utilizand un sintetizator de voce, interpretarea partiturilor la tobă, pe baza ritmului acestora și interacțiunea cu utilizatorul prin recunoaștere a vorbirii. Mai multe informații de bază despre teoria muzicii, utile pentru întelegerea acestei lucrări sunt prezentate în capitolul 4. Aplicațiile din cadrul realizării practice sunt descrise în capitolul 6, iar capitolul 5 este rezervat prezentării arhitecturii aplicației și a software-urilor open-source necesare scripturilor create.

Aceste aplicații utilizeaza software-ul open-source Audiveris, descris in subcapitolul 5.2. , pentru optical music recognition (OMR), adică citirea și recunoașterea caracterelor specifice partiturilor muzicale și convertirea acestora la un format digital structurat musicXML –descris în subcapitolul 5.3. , un standard open format pentru schimbul, partajarea și transmiterea de muzică digitală, conceput pentru utilizare rapidă și interactivă în cadrul altor aplicații.

În cadrul aplicației concepute, interpretarea vocală a partiturii muzicale de către robot se efectuează în doua moduri. În primul mod – intitulat modul didactic , se extrag informațiile necesare din fișierul .xml generat de Audiveris și notelor identificate le sunt alocate probe de sunet cu durată particularizată pe baza informațiilor extrase, sunetele aferente notelor sunt ulterior concatenate și transmise către robot pentru a fi cântate. În cel de-al doilea mod, intitulat modul sintetizator, fișierul .xml este transmis web-service-ului open-source Sinsy –“HMM/DNN-based singing voice synthesis system”, descris în capitolul subcapitolul 5.4. , rezultatul fiind transmis direct robotului pentru a fi cântat.

Interpretarea la tobă a unei partituri muzicale ritmice se efectuează similar cu primul mod de interpretare vocală, utilizând informațiile din fișierele musicXML pentru a transmite robotului NAO informațiile necesare pentru a ține ritmul la toba sa.

Interacțiunea cu utilizatorul prin speech recognition (recunoaștere a vorbirii) s-a realizat cu ajutorul web-service-ului Wit.AI, descris în capitolul subcapitolul 5.6. . Modul în care acest serviciu va fi utilizat este următorul: se vor trimite inregistrările microfonului robotului NAO către aplicația wit găzduită în cloud și limbajul vocal va fi transformat în text, prin antrenarea aplicației se vor obține rezultate din ce in ce mai precise, obținându-se rata de încredere dorită pentru ca mesajele vocale transmise să fie înțelese deplin. Pe baza acestor rezultate, se vor identifica cuvinte cheie la care robotul va formula un răspuns audio însoțit de un gest specific, ca exemplu putem da răspunsul la “salut!” sau “la revedere”.

Capitolul 6 va detalia structura proiectului practic și a aplicațiilor dezvoltate pentru a fi utilizate în cadrul interacțiunii propuse.

În capitolul 7 se vor discuta alte potențiale aplicații ce pot fi integrate în cadrul proiectului sau îmbunătățiri ale aplicațiilor deja prezentate în capitolul 6.

Interactiunea om-robot

Istoric

În aceasta sectiune vom parcurge succinct evenimentele și descoperirile ce au facut posibilă interacțiunea dintre om si robot. Este important de menționat că, deși robotica este un domeniu al secolului XX, rădăcinile acesteia datează de pe vremea grecilor, chinezilor și egiptenilor antici, roboții fiind prezenți în religie, mitologie, filosofie și folclor. O cronologie a evoluției roboticii este prezentată atât în “Timeline of Robotics”[1] cât și în “History of Robotics: Timeline” [2]. În cadrul cronologiei se face mențiune despre o întreagă orchestră artificială elaborată de artizani chinezi încă din ~200 î.e.n [1].Un alt pionier antic al „automaților” a fost Heron din Alexandria, considerat unul dintre cei mai mari savanți ai antichității. Evoluția a continuat și în perioada evului mediu și a epocii luminilor, Jacques de Vaucanson a construit o multitudine de roboți “automați” precum un android ce cântă la fluier,unul ce cântă la tobe și o rață mecanizată ce poate zbura, mânca si digera hrană.

Fig 2.1.1. – Orchestră pentru Împărat[3]

.

Figura 2.1.2. – Invențiile lui Heron din Alexandria[3]

Figura 2.1.3. – “Automații” lui Vaucanson [4]

În epoca modernă se introduce termenul de robot, ce provine din limbile slave – de la cuvântul robota, ce înseamnă muncă [5]. Roboții moderni timpurii erau de obicei controlați manual – de la apropiere sau distanță și nu prezentau semne de autonomie, odată cu avansarea tehnologiei robotice s-au dezvoltat și tehnicile de inteligență artificiala, ulterior facilitând dezvoltarea de roboți autonomi, exemplul deseori citat în lucrările de specialitate este Shakey[6], un robot capabil să analizeze comenzile primite și să le fragmenteze în bucățele mici pentru a le executa autonom. [7].

Figura 2.1.4. – Robotul Shakey[1][6]

Procesul continuu de inovare în domeniul roboților autonomi a avut ca bază progresul în domeniul roboticii bazate pe comportament și emoție, și ulterior a avut loc un proces de dezvoltare în cadrul interacțiunii om-robot prin utilizarea tehnologiilor hibride, astfel s-au obținut roboți ce dețin raționament cognitiv, exprimă emoție în interacțiunea cu oamenii, se comportă adecvat în societate relativ cu ceilalți membrii din mediul din care fac parte dar iși mențin caracteristicile și calitățile fundamentale ce îi diferențiază de om. Inițial atenția a fost acordată dezvoltării mobilității roboților autonomi, însă contribuțiile recente se concentrează asupra comportamentului [8], conduitei [9] și a emoțiilor prezentate și transmise de către robot în interacțiunea cu omul, [10] și [11] sunt lucrări recente ce descriu stadiul actual cât și provocările legate de cercetarea în domeniul emoțiilor prezentate de roboți.

Pe scurt se lucrează la perfecționarea termenului de “Robotiquette”, ce insumează normele de comportament pe care un robot trebuie să le dețină pentru a interacționa în mod natural cu oamenii într-un mediu social [12,13].

Pe de altă parte orice robot trebuie să fie supervizat de către om, o procedura rudimentară fiind aceea de teleoperare, procesul de control al robotului de către un operator uman de la distanță în mod direct, în practică acest procedeu are o aplicabilitate vastă, fiind utilizat în mai multe domenii precum industrie, explorare spațială, medicină, asistență, siguranță publică, educație și cercetare[14-16]. La celălalt capăt al spectrului sunt roboții autonomi ce sunt supervizați, prin acest termen înțelegem că un om supraveghează comportamentul robotului și intervine atunci când este necesar pentru a indica robotului modul corect de a proceda în diferite situații, a-i atribui acestuia diferite sarcini de îndeplinit, în acest timp robotul iși menține cunoștințele despre mediul înconjurător și ține cont de specificațiile și constrângerile date pentru execuția sarcinii.

HRI este astfel definit ca un domeniu de cercetare interdisciplinar cu contribuții din domenii multiple: inteligență artificială, robotică, înțelegerea limbajului natural, interacțiunea om-computer, științe sociale. Domeniu ce conține proiectarea, dezvoltarea de algoritmi și programe, testarea si perfecționarea roboților pentru a îi aduce căt mai aproape de comportamentul uman în cadrul interacțiunilor cu oamenii.

Anual, din 1992 are loc “IEEE International Symposium on Robot & Human Interactive Communication (RoMan)” care reunește cercetătorii din domeniile HRI [17]. În afară de acesta, se organizeaza periodic mai multe conferinte și workshop-uri precum “International Conference on Humanoid Robots” [18] sau “The Annual Conference on Human-Robot Interaction” [19].

Interacțiunea om – robot umanoid: provocări, soluții și exemple

Roboții autonomi ce incearcă să imite comportamentul unui om, prezintă caracteristici antropomorfe și dețin un raționament asemănător cu cel uman sunt denumiți roboți umanoizi.

Abilitatea unui robot de a interacționa cu mediul inconjurător este formată din trei categorii; interacțiuni fizice, cognitive și sociale [20].

Interacțiunea fizică între om și robot se bazează pe interacțiunea propriuzisă, feedback în cadrul acelei interacțiuni și menținerea siguranței participanților în cadrul interacțiunii. Interacțiunea fizică poate varia din punct de vedere al complexității, de la lipsa ei sau al feedbackului în totalitate până la autonomie totală și feedback multimodal complex, referința [20] prezintă o “scară” a nivelelor de interacțiune în subcapitolul 4.3.2. Pentru a obține o interacțiune fizică complexă trebuie luate în considerare mediul în care se petrece interacțiunea, timpul de răspuns al robotului și complexitatea sarcinii întreprinse de om și robot.

Interacțiunea socială este abilitatea robotului de a interacționa cu oamenii prin înțelegerea semnalelor sociale și emoționale transmise de către aceștia si formularea unui răspuns corespunzător.

Abilitațile cognitive ale unui robot se referă la capabilitatea de a putea interpreta o sarcină astfel încât aceasta să fie indeplinită corespunzător chiar și atunci când există incertitudini cu privire la mediul înconjurător sau la obiectivul stabilit în sine, la capabilitatea de a interpreta funcțiile si relațiile dintre obiectele aflate în mediul apropiat robotului, la iscusința în a interacționa cu persoane într-un mod în care doar o altă persoană ar face-o.

În cadrul mediului de cercetare al HRI apar multiple provocări ce trebuie abordate, în cazul roboților umanoizi este vorba de aspectele sociale și emoționale ale interacțiunii dintre om si android, de replicarea mișcărilor umane într-un mod natural și despre autenticitatea expresiilor si veridicitatea emoțiilor. Limbajul utilizat între om și robot este din nou o provocare, pentru că este nevoie de o recunoaștere vocală performantă și de o bună înțelegere a limbajului natural, dar și pentru că este necesar un schimb încărcat de informații între participanți, fiind nevoie de o abordare multimodală (se utilizează spre exemplu recunoaștere vocală, localizare și identificare video, recunoaștere de gesturi, recunoaștere a feței umane, dialog între robot și om).

Pentru aceste provocări au fost elaborate și soluții precum:

Învățare prin predare: Utilizează studentul robot pentru a invăța la rândul său un student uman (și/sau vice-versa), acest procedeu este dovedit de a produce beneficii motivaționale și educaționale [21], lucrarea [21] prezintă un caz de “learning by teaching a robot” bazat pe învățarea unui robot NAO să scrie corect “de mână”, în urma experimentului este dovedit că procedeul “learning by teaching” se transpune cu succes din interacțiunea om-om la interacțiunea om-robot.

Învățare interactivă: Este procesul prin care un robot și un om lucrează împreună pentru a îmbunătăți gradual autonomia robotului și calitatea interacțiunii, acest lucru este o consecință directă a faptului ca interacțiunile dintre om și robot sunt complexe, așadar nu se poate anticipa fiecare pas al interacțiunii pentru a putea preprograma comportamentul robotului. Din această cauză se utilizează frecvent tehnici de machine-learning pentru a ajuta roboții să se perfecționeze pe parcursul interacțiunii cu omul.[22]

Modelare cognitivă și metacogniție: Un model cognitiv este o aproximație a modului de gândire al omului în scopul aprofundării cunoașterii sau al predicției, prin tehnici de modelare cognitivă putem obține modele care să permită roboților să identifice starea cognitivă a omului cu care interacționează și să se adapteze ca atare. Sau putem obține un model interpretabil cu ușurință de către om pentru a genera comportamentul robotului.[22] Metacogniția este un concept ce reprezintă “cunoașterea despre cunoaștere, reflecție și demers asupra modului de producere al cunoașterii, i.e. cunoștințe și experiențe de autoreglare sau gestiune a proceselor mentale” [23]. Dezvoltarea abilităților metacognitive ajută omul în a procesa informația necesară pentru a îndeplini o sarcină și a o transfera cu ușurință intr-o situație nouă[13]. Studiul de caz [24] oferă informații despre îmbunătățirea capacității studenților de rezolvare a problemelor în urma parcurgerii cursului propus, care a oferit o bună oportunitate de învățare atât studenților cât și cercetătorilor HRI.

În cartea “Human–Robot Interaction: A Survey, Foundation and Trends in Human–Computer Interaction”[22] rolurile pe care roboții le asumă in HRI sunt clasificate astfel: supervizor [25], operator, mecanic, egal [26], mentor [27], ghid [25], asistent [25], sursă de informații [28] sau artist [29-31].

Tendințe de evoluție

Noile aplicații apărute în domeniul roboticii sunt caracterizate în prezent de interacțiuni din ce în ce mai complexe. Dezvoltarea de interfețe naturale și intuitive permite operarea sistemelor robotice complexe cu usurință, necesitând mai puțină formare (sau chiar deloc) și reducând nivelele de oboseală. Interacțiunea om-robot iși va asuma noi forme atât in mediul virtual cât și in cadrul interacțiunilor fizice [20].

Prin îmbunătățirea HRI se preconizează intrarea pe noi piețe și dezvoltarea de noi tehnologii de asistență socială ce vor crește confortul acordat oamenilor in vârstă și a celor imobilizați sau vor crește rata de success a cercetărilor de tip USAR (urban search and rescue) [32], [33]. Alte noi aplicații pot îmbunătăți nivelul de trai la serviciu, acasă, în cadrul educației și in domeniul artistic, de asemenea un parteneriat om-robot poate facilita producția în masă, manufacturarea și asamblarea în domeniul industrial. Pentru ca aceste aplicații să prindă contur, trebuie lucrat în domeniul comunicației, coexistenței si toleranței între roboți si utilizatorii acestora, roboții au nevoie de moduri naturale, sigure și satisifăcătoare pentru a interacționa cu unul sau un grup de indivizi, iar oamenii trebuie să lucreze la îndepărtarea barierelor ce stau între acceptarea roboților de către mase sau respingerea acestora.

Figura 2.3.1. – Evoluția la un model ce are la centru omul și siguranța acestuia [28]

În “Robotics 2020 Multi-Annual Roadmap”[20] este menționat că va fi nevoie de o schimbare de perspectivă cu privire la modul in care tratăm proiectarea de noi roboți, va trebui să ne indepărtăm de modelul clasic prezentat in Figura 2.3.1. ce are la centru robotul către un model al carui design are la centru ființa umană, toate aspectele de siguranță și interacțiunea fizică fiind bine definite și interconectate, astfel vom putea obține sisteme robotice complexe apropiate de caracteristicile umane.

Aceste tipuri de sisteme vor avea nevoie de dezvoltarea unor noi framework-uri ce vor ușura modul de lucru al oamenilor cu roboții, îmbunătățind modurile de utilizare ale sistemului și interpretabilitatea acestuia. Acești noi roboți vor trebui să comunice cu oamenii multimodal, nu doar prin voce ci și prin gesturi naturale, emoții, sunete și indicații vizuale. Dezvoltarea următoarei generații de roboți depinde și de stadiul de dezvoltare al algoritmilor și al componentelor hardware [20].

Barierele curente ce împiedică dezvoltarea domeniului sunt:

Lipsa platformelor standardizate

Necesitatea de a utiliza tehnologii standardizate

Atingerea anumitor standarde de siguranță în interacțiune

Costul ridicat al producției

Dezvoltare limitată în domenii de care depinde HRI (hardware sau software)

Necesitatea unei analize în detaliu pentru a identifica beneficiile aduse de achizitionarea unui robot comparat cu metoda tradițională

Incertitudinea cu privință la siguranța participanților în cadrul interacțiunii si lipsa metodelor si uneltelor pentru verificare, validare si testare a siguranței cu privire la roboți

Lipsa de conștientizare a populației cu privire la standardele industriale

Alegerea temei specifice: educația muzicală

Luând în considerare analiza efectuată în subcapitolul anterior asupra interacțiunii dintre oameni și roboți umanoizi s-a propus următoarea temă specifică: Colaborare între robotul NAO și copii preșcolari și de vârstă școlară pentru a învăța interactiv elemente de educație muzicală.

În cadrul acestei colaborări atât robotul cât și copiii vor avea un rol activ, fiind pe rând profesor și invățăcel. Spre deosebire de studiul tradițional are loc o schimbare de perspectivă, oferindu-i copilului oportunitatea de a învăța pe cineva sporește increderea în sine și dedicația față de obiectul studiat, profesorul fiind “nevoit” să cunoască bine obiectul predat pentru a putea răspunde cu succes la întrebările care îi pot fi adresate în timpul lecției. Conform [21], atunci când copii sunt nevoiți să transmită informația altcuiva, aceștia depun mai mult efort în a învăța, comparativ cu cazul în care aceștia ar învăța pentru ei înșiși.

Muzica s-a regăsit în viețile oamenilor încă din vremuri străvechi, însă foarte puține persoane pot răspunde pertinent la întrebarea “De ce iți place muzica?”. Muzica are un efect aparte asupra oamenilor, cercetătorii au dedus că deși muzica este o experiență subiectivă (nu tuturor le place același tip de muzică) efectele ei chimice asupra organismului sunt constante, creierul reacționează față de muzică în același mod în care reacționează față de o băutură rece sau o mâncare gustoasă. În articolul [34] publicat în revista Nature Neuroscience este explicat faptul ca experiența este generată de secreția de dopamină, aceasta este un element al circuitului cerebral de motivare. În toate cele trei situații menționate, atunci când dopamina se secretă produce plăcere, iar plăcerea ne face să dorim a repeta acțiunea care a dus la generarea ei.

Robotul nu va fi profesor în adevăratul sens al cuvântului, ci un participant activ în cadrul activităților. Profesorul traditional nu va fi înlocuit, ci acesta va lua un rol de supervizor, supraveghind interacțiunea și facilitând o relație strânsă între copil și robot – prin operarea robotului și formularea de propuneri, sugestii și întrebări interactive; de asemenea intervenind în cazul in care situația o cere deoarece toți participanții la interacțiune trebuie să se afle în siguranță pentru a se crea un mediu propice pentru învățat.

În cadrul interacțiunii copilul va învăța să scrie, să citească și să interpreteze notele muzicale pe portative, să înteleagă cum funcționează muzica scrisă astfel încăt să poată cânta o melodie vocal sau la un instrument, toate acestea prin intermediul profesorului traditional și ale robotului.

De-a lungul timpului întâlnim mulți muzicieni celebri care nu dețineau cunoștințe despre teoria muzicii, dar cunoașterea acesteia este necesară pentru partajarea muzicii dar și în cadrul unei formații, orchestre sau colaborări.

NAO – robotul umanoid

Figura 3.1. – Robotul umanoid NAO Evolution V5 albastru

În cadrul interacțiunii om-robot, robotul ales este NAO, robotul umanoid interactiv și personalizabil, de dimensiune medie, creat de Aldebaran Robotics. Proiectul NAO a început în 2004, iar pe parcursul anilor a fost imbunătățit cu fiecare nouă versiune. Robotul este utilizat în scopuri recreaționale, educaționale, dar mai ales în domeniul cercetării. Nao este ușor programabil prin intermediul interfeței Choregraphe cât și în mod clasic folosind limbaje de programare precum C, C++, Python și .Net Framework [35].

Această alegere este motivată atât de aspectul robotului – NAO are o înălțime de 58 cm, ~28cm lățime și o greutate de 4.3kg, de bateria ce oferă o autonomie de circa 90 de minute, prezintă diverși senzori ce fac posibilă interacțiunea cu mediul, precum senzori tactili, cu infraroșu, ultrasonic, giroscop, accelerometru, de presiune cât și camera video, microfon si difuzor. NAO poate comunica cu alte dispozitive din rețea prin intermediul conexiunii wireless, senzori cu infraroșu sau camera și microfon [35]. Nao prezintă 25 de articulații ce fac posibile mișcări asemănătoare cu ale oamenilor. În totalitate, NAO V5 prezintă 52 de senzori, 2 camere, 4 microfoane și 2 difuzoare [35] ce îi permit să simtă realitatea și să reacționeze în concordanță cu mediul în care se află.

Programarea lui NAO se poate face prin intermediul mediului Choregraphe –un mediu grafic ușor de utilizat pentru a crea animații sau comportamente și a le testa pe un robot simulat sau real și pentru a monitoriza starea curentă a robotului. Choregraphe este aplicația care permite programarea robotului NAO fară a scrie o singură linie de cod, deși există optiunea de a adauga propriile blocuri cu cod scris în limbaj Python în cadrul unei aplicații scrise in Choregraphe.

Fiind un mediu grafic ușor de utilizat, Choregraphe este deseori recomandat pentru utilizatorii noi, la baza aplicației stă framework-ul NAOqi, creat special pentru programarea robotului NAO, respectând standardele impuse în robotică.

<Placeholder, mai multe detalii despre Choregraphe, NAOqi, și PythonSDK>

Interacțiunea om-NAO

În acest subcapitol vor fi prezentate exemple de interacțiune om-robot ce îl folosesc ca robot pe NAO. Astfel putem observa proiecte și studii efecutate de cercetători și entuziaști pentru a putea ulterior stabili sarcinile ce trebuie îndeplinite in cadrul unei interacțiuni precum cea propusă.

Robotul este pe placul copiilor, având un design prietenos și o morfologie similară cu aceștia, studii precedente indică faptul că robotul umanoid NAO are un impact pozitiv în cadrul interacțiunii robot-copil [36],[37] și numeroase lucrări din domeniu documentează tratarea autismului prin interacțiunea cu NAO [38], [39].

În lucrările [36] și [37] se discută despre acceptarea roboților în cadrul învățământului de către profesori, ambele articole au la bază conceptul de Socially Asistive Robotics pentru a oferi asistență oamenilor prin interacțiune socială, nu fizică. În cadrul testelor in care s-a utilizat robotul NAO s-au obținut diferite nivele de acceptare ce au depins de publicul țintă, de familiaritatea in interacțiunea cu roboți sau de aplicația aleasă ca bază a interacțiunii (Jocuri, Chestionare, Lecții) [36]. În ce-a de a doua lucrare s-a explorat posibilitatea implementării în cadrul grădinițelor a unui sistem de asistență bazat pe roboți (KAR – Kindergarten Assistive Robotics), cercetătorii au concluzionat că acest sistem are potențial și poate fi acceptat in viitor [37].

Lucrarea [39] are ca temă interacțiunea între NAO și copii ce suferă de autism prin intermediul muzicii. Prin această interacțiune se îmbunătățesc nivelul de percepție, aptitudinile sociale și cognitive ale copiilor diagnosticați cu autism. În cadrul studiului de caz, NAO cântă împreună cu copilul la xilofon și tobă. Scopul lucrării este de a raspunde la două întrebări : 1. Poate un robot umanoid să-i învețe muzică pe copii diagnosticați cu autism? și 2. Poate un robot umanoid sa aducă îmbunătățiri în abilitățile sociale si cognitive ale copiilor cu autism prin interacțiunea cu aceștia pe baza muzicii? În urma studiului de caz s-au observat îmbunătățiri în cadrul stării copiilor, care au fost receptivi față de ceea ce le-a arătat NAO, chestionarul GARS[40] a arătat că severitatea autismului participanților a fost redusă ca urmare a sesiunilor de interacțiune cu robotul.

Fig 3.1.1. – NAO cântă la xilofon[37]

În lucrarea [41] se studiază interacțiunea între NAO și copii suferind de paralizie cerebrală. Rolul robotului este de a motiva copii să participe la terapie. S-au dezvoltat în acest scop patru scenarii interactive pe baza imitării robotului de către copil. În cadrul studiului s-au determinat diferite limitări mecanice ale robotului, precum supraîncalzirea motoarelor, căzătura robotului, miscări rigide, terminarea bateriei, erori de conexiune la internet, erori in pronunție sau recepționarea comenzilor vocale primite în cadrul dialogului. Concluziile trase au fost că robotul NAO atrage atenția copiilor indeajuns încăt să crească efectul și impactul terapiei asupra bolnavilor.

Fig 3.1.2. – NAO interacționează cu copiii în cadrul unui joc al imitației[41]

Lucrările [42] și [43](lucrare personală) explorează posibilitatea teleoperării si controlul de la distanță al robotului NAO prin intermediul gesturilor naturale, robotul imitând operatorul uman prin intermediul unui senzor Kinect v2. Deși similară cu cea a oamenilor morfologia lui NAO nu ii permite flexibilitatea și echilibrul pe care le au oamenii, identificându-se astfel potențiale limitări.

În lucrarea [44] lui NAO i se atribuie rolul de instructor de dans pentru copii. În urma studiului de caz 12 copii au dansat împreună cu NAO, fiindu-le înregistrat comportamentul.

“Multimodal Child-Robot Interaction: Building Social Bonds”[45] este o lucrare ce abordează conceptul de interacțiune multimodală in mod direct, având ca scop obtinerea unui interlocutor robot care să fie considerat egalul omului, robotul trebuie să fie capabil să inițieze, mențină, participe și colaboreze în cadrul discuției si a activității efectuată împreună cu copilul. Figura 3.1.3. prezintă interacțiunea copil-robot, iar Figura 3.1.4. reprezintă schema bloc a sistemului multimodal.

Fig 3.1.3. – Tinerii utilizatori interacționează cu robotul in diferite jocuri (quiz,imitare și dans)[45]

Fig 3.1.4. – Schema sistemului multimodal utilizat, gestionat în platforma software URBI[45]

Rezultate personale anterioare

În lucrarea personală “Comanda unui robot NAO utilizând gesturi ale mâinii”[43] menționată anterior a fost tratată posibilitatea teleoperării robotului umanoid NAO Evolution – V5 cu ajutorul datelor primite de la un senzor Microsoft Kinect for Windows v2. În urma familiarizării cu programarea robotului a fost dezvoltat un script Python ce face legătura între poziția articulațiilor utilizatorului identificate de către Kinect și NAO prin transmiterea acestor coordonate prelucrate sub forma unei comenzi pentru a opera brațele și mâinile robotului utilizând gesturi naturale.

În urma pregătirii și redactării lucrării am interacționat cu fluxul de date primit de la Kinect, cu robotul NAO și modulul Motion al acestuia și am reușit teleoperarea robotului în timp real. Aplicația dezvoltată îndeplinește ceea ce a fost propus la începutul lucrării, robotul imitănd poziția brațelor operatorului uman in mod corect, de asemenea comenzile pentru mers înainte și inchiderea/deschiderea mâinii pe baza de gesturi naturale ale mâinilor au fost implementate cu succes.

Figura 3.2.1. – Controlul bratelor lui NAO, bazat pe gesturi naturale ale operatorului [43]

Experiența căpătată in cadrul lucrării de diploma poate fi utilă în cadrul lucrării propuse, fiind deja familiar cu robotul NAO, programarea lui prin Python SDK și cu dispozitivul Kinect, acesta putând fi utilizat pentru a recunoaște gesturile din cadrul interacțiunii propuse.

Noțiuni generale de Teorie Muzicală

“Muzica folosind sunetul ca element de bază al construcției sale sonore este definită ca artă a sunetelor.” [46]

Sunetele muzicale se deosebesc de celelalte sunete prin cele patru calități conferite de vibrațiile periodice ale corpurilor elastice: înălțime, durată, intensitate și timbru. Reprezentarea celor patru calități ale sunetelor muzicale în scris se numește notație muzicală, înălțimea sunetelor muzicale se reprezintă în scris prin portativ, chei, note și alterații.

Portativul este o liniatură specială formată din cinci linii paralele, orizontale și echidistante între ele. Pe portativ se pot scrie un maxim de 11 note muzicale, una pe fiecare linie și fiecare spațiu al portativului. Sunetele mai grave sunt notate la baza portativului iar cele mai acute sunt notate crescător, în susul portativului. În cazul în care nu sunt suficiente cinci linii ale portativului se pot utiliza linii suplimentare, atât deasupra căt și dedesubtul portativului, păstrăndu-se paralelismul și echidistanța liniilor portativului inițial.

Figura 4.1. – Portativ cu patru linii suplimentare, două deasupra și două dedesubt [46]

Cheia muzicală este un semn grafic întălnită la începutul portativului, aceasta indică înălțimea precisă și numele unui sunet din scara generala muzicală, în funcție de care se determină numele și înălțimea celorlalte sunete de pe portativ. De obicei se utilizează trei chei, cheia Sol, cheia Do, și cheia Fa. Muzica înaltă este de obicei scrisă în cheia Sol, cheia Do este utilizată pentru scrierea sunetelor cu intensitate mijlocie, iar cheia Fa este utilizată pentru sunetele din registrul sonor grav.

Figura 4.2. – Simbolurile celor trei chei, Sol, Fa și Do

Notele muzicale sunt notațiile in scris pentru sunetele muzicale, șapte la număr, denumite “DO – RE –MI –FA –SOL –LA –SI” de către călugărul Italian Guido d’Arezzo, după primele silabe ale unui imn latin. În notația internațională, notele sunt notate cu primele 7 litere din alfabet, conform figurii 4.3.

Figura 4.3. – Notații internaționale pentru note și pozitia lor pe portativ pentru cheia Sol

Alterațiile muzicale sunt simboluri ce indică modificarea înalțimii sunetelor, acestea sunt: diezul ( ♯ ) – indică faptul că următorul sunet va fi mai înalt cu un semiton, bemolul(♭) –indica faptul că următorul sunet va fi mai jos cu un semiton, becarul ( ♮ ) –indică anularea efectului celorlalte alterații și intonarea sunetului la înalțimea sa naturală.

Durata sunetelor se realizează în scris prin note, pauze, punct sau legato. Valorile de note și pauze iși primesc numele de la raportul dintre nota întreagă și diviziunile directe ale acesteia. O notă întreagă este formată din două doimi, o doime din două patrimi, o pătrime din două optimi și tot așa, până la șaizecipătrime. Din perspectiva inginerească ne putem gândi la un raport binar, bazat pe 2 și puterile sale (4,8,16,32,64). Pentru fiecare valoare de notă există și un semn de tăcere corespunzător.

Figura 4.4. – Diviziunea normală a valorilor binare

Punctul notat în dreapta notelor și a pauzelor prelungește durata acestora cu ½ din valoarea lor de bază, de exemplu ,nota . va avea durata egală cu + .

Legato de prelungire reprezintă însumarea de note de aceeași înalțime prin unirea acestora cu un semn grafic în formă de arc :

Figura 4.5. – Exemplu de note grupate, sau note contopite prin legato

Gruparea notelor cu o bară se utilizează pentru notele cu durate scurte și are ca beneficiu faptul că acestea sunt mult mai ușor de citit pe portativ. [47]

Aceste noțiuni de teorie a muzicii sunt necesare pentru a putea înțelege partituri simple și a le putea transforma într-un cântec ce poate fi interpretat de robot. De asemenea aceste cunoștințe pot fi transmise copiilor de către profesor sau robot, mai jos sunt ilustrate două exemple de partituri ce vor fi utilizate în cadrul interacțiunii, restul găsindu-se atașate în anexă.

Figura 4.5. –Exemple de partituri ce vor fi folosite în cadrul aplicațiilor concepute

Arhitectura aplicatiei si resursele utilizate

Pentru realizarea practică au fost propuse următoarele lucruri:

Recunoașterea și transformarea partiturilor muzicale într-un limbaj ce poate fi înțeles de computere

Interpretarea unei partituri muzicale de către NAO la xilofon sau tobă în cadrul interacțiunii

Interpretarea unei partituri muzicale de către robot în mod didactic (pe note) sau în versuri

Dezvoltarea unui mediu de comunicare între copii și robot îmbinând dialogul și utilizarea gesturilor

Utilizarea interfeței video a robotului sau a senzorului Microsoft Kinect v2 pentru a recunoaște gesturi cheie ale copilului în cadrul interacțiunii și formularea de răspunsuri pe baza acestora

Utilizarea sistemului de “face tracking & recognition” al robotului pentru a crește calitatea interacțiunii

Se dorește realizarea a cat mai multor puncte din cele propuse și dezvoltarea unui meniu ce are ca scop apelarea aplicațiilor dezvoltate. În următoarele subcapitole vor fi prezentate resursele auxiliare necesare îndeplinirii acestor sarcini cât și motivația pentru alegerea lor. Funcționalitatea aplicațiilor create va fi prezentată în capitolul 6.

Optical Music Recognition

Optical Music Recognition (OMR) sau Music Optical Character Recognition este un sistem utilizat pentru recunoașterea simbolurilor din partiturile muzicale și transformarea acestora, din formatul inițial (deseori .PDF sau .PNG) în format MIDI, NIFF sau MusicXML pentru a putea fi utilizate în cadrul altor aplicații ce utilizează informația din fișierul generat pentru a crea muzică digitalizată.

OMR este o sarcină foarte dificilă datorită lipsei unui algoritm robust pentru localizarea și identificarea simbolurilor muzicale în prezența liniilor portativului. De asemenea, din cauza faptului că o partitură muzicală are legături strânse între note, durata lor, și versuri, este foarte posibil ca în urma procedeului de recunoaștere să apară greșeli de citire sau asociere, identificarea nefiind întotdeauna consistentă.

Alături de termenul OMR este des menționat, în lucrările de specialitate, termenul de OCR (Optical Character Recognition), dar cele două procedee rar împărtășesc aceiași algoritmi pentru recunoașterea de tipare, exceptând cazul citirii versurilor de sub portativ, unde este de preferat utilizarea unui sistem OCR. O diferență importantă între cele două este că informația identificată de un sistem OCR este unidimensională (text) pe când informația despre simbolurile muzicale de pe partitură sunt bidimensionale (localizarea notelor pe portativ și determinarea duratei acesteia prin identificarea caracteristicilor specifice ). Simbolurile muzicale din cadrul unei partituri sunt formate din componente multiple, care pot fi combinate și amestecate în multe moduri, acest lucru ridicând nivelul de complexitate al problemei de recunoaștere a caracterelor muzicale. Conform studiului efectuat în [48], din cauza complexității generate de faptul că simbolurile prezente pe portativ sunt bidimensionale, sistemele OMR nu funcționează foarte bine în cazul partiturilor scrise de mână sau a celor digitale cu calitate redusă a imaginii.

O platformă pentru recunoașterea automată a unei partituri muzicale este alcătuită din patru etape principale: preprocesarea imaginii, recunoașterea simbolurilor muzicale, reconstrucția informației muzicale pentru a putea construi o descriere logică a notației muzicale și generarea unui model ce conține descrierea partiturii muzicale într-un limbaj interpretabil.

Figura 5.1.1. – Arhitectura generală a unui sistem OMR [48]

În Figura 5.1.1. se observă că fiecare dintre cele patru etape sunt la rândul lor, subdivizate în alte etape.

În cadrul etapei de preprocesare se dorește reducerea a cât mai mult zgomot prezent în imaginea dată, în acest sens se utilizează tehnici precum cele incluse în primul bloc din figura prezentată. Utilizarea acestor tehnici pentru a îmbunătăți calitatea imaginii poate duce la un proces de recunoaștere mai robust și mai eficient. Problemele ce apar în cadrul acestei etape au de a face cu îndepărtarea eronată a unor elemente cu importanță din cadrul partiturii, deoarece aceasta etapă este prima, erorile se pot propaga la celelalte etape.

În cadrul etapei de recunoaștere a simbolurilor muzicale, se începe deseori cu detecția și eliminarea liniilor portativului și păstrarea simbolurilor muzicale și a versurilor(1), urmat de izolarea și segmentarea simbolurilor muzicale(2) și de recunoașterea și clasificarea acestora(3). Trebuie să ținem cont de bidimensionalitatea documentelor muzicale, în care liniile portativelor se intrepătrund cu mai multe simboluri muzicale care la rândul lor sunt note muzicale, pauze sau alterații ce trebuie identificate și tratate diferit pentru a fi interpretate în mod corect. Acest pas al etapei a doua devine mult mai complicat atunci când se incearcă recunoașterea unei partituri scrise de mână, datorită reprezentării diferite a simbolurilor. În ultimul pas al etapei, se dorește clasificarea simbolurilor muzicale, clasificatoarele sunt construite pe baza unui set de simboluri muzicale cunoscute împărțite aleator în seturi de antrenament și validare. Ca intrare, clasificatorul primește o grupare de pixeli ce reprezintă segmentul unui simbol sau un simbol, de asemenea s-au considerat și parametrii de intrare ce conțin informații despre componentele conectate cu simbolul sau orientarea acestuia.

Ce-a de a treia etapă se ocupă cu reconstruirea notațiilor muzicale, unde simbolurile segmentate și identificate în etapa anterioară sunt contopite pentru a forma simboluri muzicale, simbolurile detectate sunt interpretate și le este atribuit un înțeles muzical. În cadrul acestui pas, se pot corecta posibilele ambiguități care au apărut în cadrul etapei precedente.

Ultima etapă are ca scop obținerea ieșirii sistemului, pe baza informațiilor obținute din etapele anterioare, sub forma unui format standardizat ce poate fi citit și interpretat digital de obicei ieșirile se găsesc în format MIDI, GUIDO sau MusicXML.

Deoarece un sistem OMR automatizat capabil să recunoască partituri scrise de mână sau digitale cu robustețe și precizie ridicată este un obiectiv dificil de realizat, sistemele de recunoaștere muzicală se bazează pe potențialele corecturi ce pot fi aduse de către utilizator în mod interactiv, iar sistemul poate învăța din corecturile aduse, astfel încăt sistemele interactive de recunoaștere muzicală pot prezenta o soluție realistă a acestei probleme, cu costul pierderii potențialului de automatizare completă.

În cadrul realizării practice, nu a fost creat propriul motor de OMR ci s-a optat pentru utilizarea unei platforme deja existente, chiar dacă nici o platformă activă în prezent nu are capabilități adaptive, iar corecturile manuale efectuate de utilizator sunt utilizate doar în cadrul rulării curente a partiturii alese.

Tabelul 5.1.1. – Software-uri sau platforme OMR

În tabelul prezentat sunt enumerate diferite software-uri sau platforme ce pot efectua OMR, dintre acestea pentru aplicațiile acestei lucrări s-a ales utilizarea software-ului Audiveris, deoarece este open-source, produce output în format .XML sub standardul musicXML, poate fi utilizat din linia de comandă așadar utilizabil în scripturi Python, este actualizat frecvent iar echipa mică de dezvoltatori lucrează mult pentru a oferi un mediu stabil și bun din punct de vedere calitativ.

Audiveris

Figura 5.2.1. –Logo-ul Audiveris [53]

Audiveris OMR [53], este un software de recunoaștere muzicală pentru notația muzicală occidentală, ce funcționează cu partituri tipărite, convertindu-le într-o formă ce poate fi citită de computer. Audiveris a fost creat de către Hervé Bitteur și este menținut în prezent de către acesta și o echipă de 4 dezvoltatori, Audiveris este scris în JAVA și publicat ca free software.

Principiul de funcționare al Audiveris urmărește diagrama de la figura 5.1.1. , parcurgând cele patru etape, structurate sub forma a 20 de pași, ilustrați in figura 5.2.2, extrasă din meniul software-ului, si explicați sumar pe wiki-ul Audiveris [55],

Figura 5.2.2. –Pașii pentru procesarea partiturilor

Ciclul de viață al unui proiect Audiveris urmează următorii pași:

Proiectul este creat pe baza fișierului de intrare, ce poate conține una sau mai multe imagini reprezentând o partitură muzicală.

Pasul LOAD incearcă să incarce prima imagine din fișierul de intrare

Pasul Binary transformă imaginea în alb-negru și va fi folosit ca referință următoare pentru ceilalți pași în cadrul acestui proiect.

Orice alt pas din lista menționată se construiește pe rezultatul pasului anterior. Datele pot fi salvate la sfărșitul oricărui pas pentru o încărcare viitoare.

Observație: Procesul de OMR nu se poate mișca înapoi, de exemplu de la pasul CUE_BEAMS înapoi la REDUCTION, dar acesta se poate relua oricand de la pasul BINARY și până la REDUCTION.

Figura 5.2.3. Diagrama reprezentând ciclul de viață al unui program Audiveris[55]

Motorul OMR funcționează prin parcurgerea acestor pași, este posibilă rularea cap-coadă a acestor pași pentru o partitură dată, iar la final se verifică rezultatul și se observă că recunoașterea automată a caracterelor muzicale nu este o știință. Dar deseori rezultatul nu este departe de ceea ce așteptam, și cu puțin ajutor extern de la utilizator acesta se poate corecta astfel încăt să fie cel dorit, de obicei corecturile se efectuează la următorii pași:

La pasul REDUCTION, capetele potențialelor note sunt combinate cu potențialele codițe sau bări de legătură pentru a forma note de care algoritmul este sigur ca sunt de încredere, ce ulterior sunt “reduse” , astfel în cadrul pasului SYMBOLS, pixelii acestor note nu vor fi prezentati clasificatorului de simboluri. Este mult mai ușor de corectat o greșeală fals pozitivă după acest pas, decât în cadrul pasului final, PAGE.

Pentru identificarea obiectelor de tip text din partitură (titlu, versuri). Audiveris utilizează Tesseract OCR[56], un motor de Optical Character Recognition de sine stătător, asupra căruia are foarte puțin control, utilizatorul putând corecta rezultatul după execuția pasului TEXTS.

PAGE este pasul unde rularea programului ia sfărșit, și afișează o partitură unde se poate observa și corecta rezultatul final.

Clasificatorul de simboluri al software-ului Audiveris este bazat pe Deep Learning și creat utilizând biblioteca Java “Deeplearning4j”[57]. În cadrul programului sunt utilizate două clasificatoare bazate pe rețele neurale: unul de bază –ce are ca input imagini și pixeli ai simbolului cu două straturi, discriminativ (se obțin performanțe mai bune din cauza numarului mic de variabile necesar calculelor) –utilizat pentru detecția simbolurilor de încredere(vector de 110 valori), și unul deep, ce primește ca input pixelii simbolurilor (vector de 1152 de valori), cu o arhitectură convoluționară cu 6 straturi, utilizat în cadrul pasului SYMBOLS, clasificator ce se descurcă foarte bine la procesul de clasificare, dar are rezultate îndoielnice cand vine vorba de ranking, dezvoltatorii spun ca acest lucru este datorat funcției de activare softmax.

Mai jos este prezentat un exemplu de rulare al lui Audiveris ce are ca intrare o partitură ce conține cântecul “Happy Birthday”:

Figura 5.2.4. Imagini din cadrul rulării audiveris pentru o partitura aleasă

În imaginea 1 din figura 5.2.4. se găsește partitura încărcată din fișierul .pdf, în imaginea nr 2 se poate vedea că după rularea tuturor pașilor, notele de pe portativ au fost identificate cu succes însă există o greșeala la versurile de sub portativul al 2-lea care nu au fost setate corect ca “lyrics” ci doar ca “text”, este astfel necesară o corectură manuală a rezultatului, precum se poate observa în imagine.

În figura 5.2.5. se poate observa rezultatul final al rulării programului plus aplicarea corecturilor de rigoare, astfel partitura este corect citită și se poate exporta în limbaj MusicXML.

Figura 5.2.5. –Starea partiturii după execuția ultimului pas și a corecturilor manuale

MusicXML

MusicXML[58] este un standard open format pentru schimbul de muzică digitală. Acesta a fost proiectat pentru partajarea partiturilor între diferite aplicații, pentru arhivarea lor și utilizarea ulterioară în viitor. MusicXML completează formatele de fișiere native utilizate de Finale[59] și alte programe, care sunt concepute pentru utilizare rapidă și interactivă. La fel cum fișierele MP3 au devenit sinonime cu partajarea muzicii înregistrate, fișierele MusicXML au devenit standardul pentru partajarea muzicii interactive. Versiunea MusicXML 1.0 a fost publicată în Ianuarie 2004, în ziua de astăzi, versiunea utilizată este 3.1 publicată în Decembrie 2017.

În prezent peste 230 de aplicații includ suport pentru MusicXML [60]. Aceste aplicații sunt menționate la [61], dintre acestea menționăm Finale[59], Sibelius[62], un parser în Matlab[63,64] și desigur, software-ul Audiveris[53] prezentat în subcapitolul anterior.

Figura 5.3.1. –Două fragmente din fișierul .xml ce indică note muzicale și caracteristicile lor

În fișierul .xml , informații despre fiecare notă a partiturii sunt stocate între tagurile <note> și </note> fiecare cu particularitățile <pitch>, <step>, <octave>, <duration>, <voice>, <type>,<time-modification>, <notations>, <articulations>, <syllabic>,<lyric>. În <step> se găsește denumirea notei în notație internatională: C D E F G A B care conform teoriei prezentate în capitolul 4 corespund notațiilor Do Re Mi Fa Sol La Si.

<placeholder, POSIBIL CAPITOL DESPRE SINTETIZATOARE VOCALE>

SinSy

Fișierul .xml rezultat în subcapitolele anterioare poate fi primit ca input și cântat de un sintetizator vocal. Inițial a fost considerat software-ul Vocaloid[65], bine cunoscutul sintetizator vocal creat special pentru a cânta, produs de compania japoneză Yamaha. Dar s-a optat pentru utilizarea unui software open-source ce poate primi ca intrări fișiere de tip musicXML, format .xml sau .mxl, adică să fie compatibil cu outputul dat de Audiveris. Așadar sintetizatorul de voce ce va cânta partiturile recunoscute și transformate în limbaj MusicXML de audiveris este SinSy: un sintetizator vocal open-source ce produce rezultate bune în limbile japoneză, engleză și mandarină. Sinsy este licențiat sub licență modificată BSD pe Sourceforge [66], cu un serviciu online disponibil la http://sinsy.jp/ [67].

Din punct de vedere tehnologic sintetizatorul vocal al serviciului Sinsy se bazează pe HMM (Hidden Markov Models sau Modele Markov cu stări invizibile/ascunse) și DNN (Deep Neural Networks)[68] pentru a învăța din probe de sunet produse de oameni și ulterior generarea de sunete vocale sintetice ce se potrivesc oricărei partituri date. Partea de antrenare a sistemului se este implementată ca o versiune modificată de HTK[69], din nefericire partea aceasta a implementării nu este disponibilă publicului larg, fiind rezervată în mare echipei de dezvoltatori.

Fișierul MusicXML (format .xml) poate fi trimis serviciului web mergând pe http://sinsy.jp/, încărcănd manual fișierul .xml și selectănd parametrii corespunzători din lista afișată : limba, vocea, variatiuni ale vocii(gender parameter, vibrato power, pitch). Se apasă butonul Send și se poate descarca fișierul rezultat în format .wav de îndată ce procesarea a avut loc și acesta este disponibil.

Speech Recognition

Conform Oxford Dictionary[70] , Speech Recognition este “Procesul ce ii permite unui computer să identifice și răspundă la sunetele produse de vorbirea umană”. Odată cu dezvoltarea domeniului inteligenței artificiale aplicațiile pentru recunoaștere a vorbirii nu mai sunt limitate doar la computer, acestea sunt utilizate în cadrul smart TV, a smartphone-urilor, în controlul de dispozitive IoT și al roboților.

Recunoașterea vorbirii (speech recognition) este domeniul interdisciplinar care se ocupă cu dezvoltarea de algoritmi și platforme prin care un computer (sau alt tip de sistem de calcul) identifică în mod corect cuvintele vorbite de către oameni. Un sistem de recunoaștere a vorbirii poate fi dependent de vorbitor sau nu. Un sistem dependent de vorbitor este proiectat pentru a fi utilizat de un singur vorbitor și instruit în prealabil să ințeleagă un singur tip de vorbire. Sistemele independente sunt destinate utilizării de către mai mulți vorbitori, cu timbre sau volume vocale diferite și este în mod firesc mai dificil de realizat. Datorită naturii interacțiunii propuse, se subînțelege că va fi nevoie de un sistem de recunoaștere a vorbirii independent de vorbitor, deoarece în interacțiunea cu NAO numărul interlocutorilor va fi >1.

Aceste platforme de lucru , în cele mai multe cazuri, se bazează pe obținerea cuvintelor sau frazelor din cadrul unei intrări audio, convertită intr-o spectogramă (figura 5.5.1.), ce este prelucrată printr-o tehnică avansată de machine learning: HMM (Hidden Markov Models sau Modele Markov cu stări invizibile/ascunse), CRF(Conditional Random Fields), RNN(Recurrent Neural Networks, sau Rețele Neurale Recurente), DNN (Deep Neural Networks) sau o combinație hibridă între acestea[71].

HMM – Hidden Markov Model

Un HMM este definit ca “un proces dublu stohastic, cu unul dintre procese neobservabil (este ascuns) ce poate fi observat doar printr-un alt set de procese stohastice care produc secvența simbolurilor observate”[72]. Pe scurt stările lanțului Markov generează date ce sunt observabile, în timp ce secvența de stări rămâne ascunsă. În cadrul unui HMM, sunt definite următoarele: alfabetul de ieșire, spațiul stărilor, starea inițială, distribuția de probabilitate a tranzitiilor dintre stări și probabilitate de distributie a ieșirilor, asociate tranzitiilor de la starea s la s’, .

Figura 5.5.1. –Model HMM bazat pe sunete fonetice numite “phone” sau “phoneme” pentru a obține un cuvânt aflat în vectorul acustic[73]

Figura 5.5.2. –Arhitectura unui recunoscător bazat pe HMM[73]

ANN – Rețele neurale artificiale

Rețelele neurale artificiale (ANN) reprezintă o tehnică de procesare a informațiilor ce incearcă să imite modul în care creierul uman funcționează. O rețea este compusă dintr-un număr de elemente interconectabile, denumite neuroni artificiali, care lucrează împreună pentru a rezolva probleme specifice. Modul în care conexiunile sunt organizate și ponderile acestor conexiuni determină ieșirea rețelei. Fiecare rețea neurală este configurată pentru o aplicație specifică, precum clasificări sau recunoaștere de tipare, printr-un proces de antrenare. Învățarea implică ajustările ponderilor alocate conexiunilor. Rețelele neurale pot diferi din punct de vedere al modului în care neuronii sunt conectați între ei, de modul în care tiparele de activitate sunt transmise de-a lungul rețelei, prin modul în care acestea învață și prin tipurile specifice de calcul pe care le efectuează neuronii.[74]

Mai jos este reprezentată o diagramă a unei rețele neurale cu trei straturi: stratul de intrare, stratul de ieșire și un strat ascuns. Acești neuroni sunt conectați prin conexiuni de la fiecare neuron al stratului curent la fiecare neuron al stratului următor. Fiecărui neuron ce nu face parte din stratul de intrare îi corespunde o funcție de transfer, liniară sau neliniară, și are forma unei ecuații algebrice sau diferențiale, pe baza acestei funcții se stabilește dependența dintre intrarea în neuron și ieșirea acestuia.

Figura 5.5.3. Diagrama unei rețele neuronale de tip feedforward cu trei straturi

O rețea neurală deep (DNN – Deep Neural Network) este o rețea neurală cu un anumit nivel de complexitate, de obicei cu mai mult de două straturi ascunse. Utilizate pentru a clasifica și sorta informații în moduri mai complexe decăt simple corelații între intrări și ieșiri.

O rețea neurală recurentă (RNN – Recurrent Neural Network) este o clasă a rețelelor neurale unde conexiunile dintre noduri formează un graf orientat de-a lungul unei secvente. Informația circulă într-o buclă, starea curentă afectând starea viitoare. Atunci când rețeaua ia o decizie, aceasta este luată pe baza intrării curente dar și a ceea ce a învățat din intrările primite în trecut, deoarece ieșirea rețelei la pasul t este introdusă ca intrare la pasul t+1 . O RNN are memorie internă și poate reține outputurile anterioare în cadrul rețelei.

În prezent, majoritatea serviciilor de speech recognition disponibile folosesc una dintre tehnicile menționate anterior, sau o combinație hibridă între acestea, cea mai des întalnită fiind HMM+RNN. Însă faptul că modelele Markov cu stări ascunse necesită o cantitate considerabilă de cunoștințe specifice pentru a fi dezvoltate reprezintă un dezavantaj al hibridului. RNN nu au putut fi folosite individual pentru această sarcină deoarece funcțiile obiectiv ale unei rețele neurale standard trebuie definite separat pentru fiecare moment al antrenării, o soluție a acestei probleme este segmentarea datelor de intrare pentru antrenament, și post procesarea iesirilor rețelei pentru a obține secvența finală.

Figura 5.5.4. – Spectograma unui semnal [75]

Rețelele neurale recurente sunt utile pentru acest tip de sarcini deoarece fiecare literă înțeleasă influențează probabilitatea următoarei. De exemplu atunci când se transmite cuvântul “speech”,sansele pentru a spune “ch” după ce se aude “spee” sunt destul de mari. Spectograma creată pe baza înregistrării audio este segmentată în fâșii cu durata de ~20ms , fiecare fâșie este atribuită unei litere, și la ieșire vom obține o secvență de litere asemănătoare cu cuvântul rostit, de exemplu “sss peeech”, după post-procesare –înlăturarea spațiilor și combinarea literelor duble într-una singură se va obține, cu puțin noroc cuvântul dorit, “speech”, printre alte alternative precum “spech”, “spich” sau alte variații ce pot fi înțelese. Pe baza probelor de antrenament și a feedbackului uman se va alege varianta potrivită, astfel ponderile rețelei neurale se vor modifica în favoarea cuvântului dorit și aceasta va identifica corect în următoarele încercări.

Fig 5.5.5. Speech Recognition utilizănd o Rețea Neurală Recurentă[75]

Pentru a antrena rețeaua, sunt desigur nevoie de foarte multe probe de sunet ce trebuie analizate manual și corelate cu ieșirile rețelei. Acest lucru este foarte greu de realizat din punctul de vedere al unei singure persoane, așadar va fi nevoie de un set de date consistent pentru a obține un sistem de recunoaștere a vorbirii valid, precis, independent de vorbitor, cu vocabular de dimensiune largă și disponibilitate perpetuă sau spontană[76].

Speech Recognition ca Serviciu

Din această cauză, marile companii din domeniul IT&C au achizitionat start-upurile recente sau si-au dezvoltat propriile sisteme de recunoaștere audio:

Tabelul 5.5.1. – Servicii de Speech Recognition clasificate ca software proprietar[77-81]

Dar există și servicii open source, care deseori rulează local și pot fi folosite cu ușurință pe dispozitive precum Raspberry-PI, dintre acestea se mentionează: Sphinx, Mycroft, HTK, Kaldi, Mozilla DeepSpeech. [69],[82-85]

Wit.ai

Dintre serviciile de speech recognition mentionate mai sus, Wit.ai[78] a fost selectat ca serviciul ce va fi utilizat în cadrul realizării practice.

Avantajele acestui serviciu sunt gratuitatea,compatibilitatea cu limbajul Python, disponibilitate la distanță, capabilitatea de a fi integrat în cadrul aproape oricărui program prin intermediul api-ului său.

Dezavantajele constau în faptul că este mai dificil de implementat decât API.ai[77] sau IBM Watson[79], statutul de “Beta” al sistemului –actualizările periodice pot modifica functionalitatea aplicațiilor deja existente, iar faptul că este deținut de către Facebook prezintă un dezavantaj din punct de vedere al securității datelor, respectiv al utilizării datelor în alte scopuri decăt cele menite de utilizator în moduri necunoscute de către acesta.

Modul în care serviciul funcționează pentru speech-to-text este următorul: se oferă un server access token ce permite accesul la aplicația creată online:

Acest token se utilizează în aplicația concepută pentru a ne autentifica la server și pentru a urca probele de sunet înregistrate, în urma prelucrării acestei probe de sunet se primește înapoi un mesaj ce conține textul perceput din înregistrarea primită.

Fiecare răspuns al serviciului poate fi validat sau, daca este greșit sau nu corespunde cu ceea ce s-a transmis, corectat de către utilizator în scopul antrenării rețelei neuronale. Cu cât există mai multe validări, cu atât crește rata de încredere pentru răspunsul așteptat. De asemenea este de preferat ca înregistrările audio să fie diverse, cu tonalitate diferită sau voci diferite, pentru a îmbunătății astfel serviciul din punct de vedere al independenței față de vorbitor.

Pentru antrenarea rețelei neuronale pe baza înregistrărilor deja efectuate se poate face accesând website-ul serviciului wit.ai, spre exemplu https://wit.ai/Andrei-UPB/appname/inbox/voice este Inboxul unde se primesc pentru validare probele vocale transmise serviciului prin utilizarea tokenului dat.

Figura 5.6.1. –Modalitatea de antrenare a serviciului speech-to-text

Metoda de învățare nu necesită cunoștințe avansate și arată ca în Figura 5.6.1. , se poate reda înregistrarea apasând butonul play din centrul paginii, iar mai apoi se doreste introducerea manuală de către utilizator a ceea ce se află în înregistrare. Textul scris cu albastru reprezintă ceea ce serviciul a crezut că se află în cadrul altor înregistrări trimise, și așteaptă validare sau corectare pentru acestea.

Pentru înregistrarea “Hello, my name is NAO” din imaginea următoare, sistemul a fost destul de aproape, producând următorul rezultat, desigur că serviciul Wit nu cunoaște faptul că în cadrul înregistrării, s-a menționat numele robotului –NAO , nu cuvăntul “now” (acum).

Fig 5.6.2 Exemplu de înregistrare ce conține un nume propriu ce nu a putut fi găsit printre rezultate, identificând în schimb un cuvânt cu aceeași pronunție, mult mai des întalnit.

Python , pygame și alte module utilizate

Python este un limbaj înalt de programare open-source, utilizat atât pentru programe de sine stătătoare cât și în scripting. Python este un limbaj gratuit, puternic și foarte popular datorită simplitătii limbajului, aspectului estetic plăcut și a ușurintei cu care se pot adauga noi module. Uniformitatea codului scris în Python și modul de indentare permite codului să fie ușor partajabil și înțeles cu ușurință de cititor.

Limbajul Python a fost dezvoltat în anii ’80 de către Guido van Rossum, Python 2 a fost publicat în 2000 și a prezentat multe îmbunătățiri față de prima versiune. În 2008 a aparut Python 3.0, noua versiune fiind incompatibilă cu precedentele, de atunci însă au fost actualizate ambele versiuni 2 și 3, Python 2 fiind încă necesar pentru anumite sisteme ce au fost concepute cu o versiune de Python 2. Ultima versiune de Python 2 este 2.7.15, aceasta rămânând neschimbată oferă atât un avantaj celor ce sunt confortabili cu ea sau utilizare pentru aplicații cu support doar pentru Python 2, dar și un dezavantaj. Python 3.5.6 este ultima versiune de Python 3 aparută, această versiune este în continua dezvoltare și este utilizată pentru aplicații mai recente, deoarece sunt rezolvate multe neplăceri din versiunea precedentă.

Biblioteca standard Python poate fi extinsă prin adăugarea de biblioteci adiționale, numite module, care oferă unelte pentru interacțiunea cu pagini xml/http, programare numerică, dezvoltarea de jocuri și aplicații, protocol SSH, lucru cu rețele neurale sau deep learning. De exemplu, modulul Paramiko reprezintă implementarea protocolului SSHv2 în python, oferind funcționalitate client și server, permițând conectarea la alte dispositive via SFTP/FTP/SCP. Modulul BeautifulSoup se ocupă cu parsarea xml și html, astfel încăt pot fi descărcate resurse online direct din scriptul .py. Pygame este modulul unde se pot dezvolta jocuri 2d în cadrul python, și este utilizat pentru meniul aplicației dezvoltate în cadrul realizării practice dar și a unui joc interactiv destinat copiilor din cadrul interacțiunii.

Deoarece NAOqi beneficiază de PythonSDK, Python este limbajul de programare preferat de dezvoltator iar toate celelalte programe/platforme prezentate în acest capitol pot fi utilizate in limbaj Python, aplicația principală și toate scripturile ce interacționează cu robotul NAO au fost dezvoltate în Python 2.7.

Prezentarea Aplicației și descrierea funcționalității

Aplicația dezvoltată intitulată “Multimodal Interaction with the NAO robot” constă dintr-un meniu dezvoltat în pygame și o serie de scripturi Python care conțin aplicații ce pot fi utilizate de către NAO în cadrul interacțiunii propuse, precum:

citirea unei partituri muzicale aflate în format digital și interpretarea acesteia pe note (solfegiu)

interpretarea partiturii utilizand un sintetizator de voce

interpretarea partiturilor la tobă, pe baza ritmului acestora

interacțiunea cu utilizatorul prin recunoaștere a vorbirii și utilizarea gesturilor

joc pe computer dezvoltat în pygame

Meniul Principal

Meniul aplicației a fost elaborat în Python utilizând modulul pygame, de obicei destinat conceperii de jocuri 2d, acesta arată ca în imaginea 6.1.1. prezentată mai jos. Conține un selector de limbă între limba engleză și limba română, patru butoane interactive pentru fiecare script aplicativ în cadrul interacțiunii și unul de ieșire. Prin apăsarea imaginii ce conține note muzicale pe un portativ în valuri, se poate juca un mini joc pe computer dezvoltat tot în pygame pentru a îmbogății calitatea interacțiunii atunci când există pauze în cadrul activității sau ,pentru moment, robotul este indisponibil.

Figura 6.1.1. –Meniul Principal alături de linia de comandă în care se vor introduce diverși parametrii pe parcursul rulării scripturilor

Modul Didactic / Didactic Mode

Modul didactic va trata posibilitatea interpretarii vocale de către robot a unei partituri muzicale simple utilizând 8 fișiere audio cu extensia .wav ce reprezintă probe de sunet ce corespund notelor gamei Do major. Intrarea va fi o partitură muzicală, iar rezultatul o melodie formată din probele de sunet date, modificate corespunzător, pe care robotul NAO o va cânta.

Figura 6.2.1. –Diagrama ce descrie firul de execuție al modului didactic

Pentru a putea fi inteleasă de către computer, partitura va trebui scrisă într-un format interpretabil, Audiveris ne ajută să obținem acest lucru prin convertirea de la partitură la un fișier .MXL , acesta este un fișier .xml arhivat, deci va trebui dezarhivat prin intermediul unui program de arhivare, în scriptul curent se utilizează 7zip. Odată extras, fișierul musicXML ce conține informații despre partitura dată poate fi parcurs pentru extragerea informației necesare.

Fragmentul de cod pentru rularea Audiveris și extragerea fișierului .xml din arhiva obținută este de forma:

Figura 6.2.2. –Fragment de cod pentru rularea Audiveris și extragerea fișierului xml la destinația dorită

Extragerea informațiilor de interes din fișierul .xml, se efectuează în Python prin utilizarea modulului inclus xml.dom.minidom [86]. Se parsează documentul și se extrag informații despre note (<step>, <octave> și <duration>). În cadrul scriptului se va obține o listă cu fiecare nota de pe portativ ce conține caracteristicile menționate. Fiecare notă este de forma „notaoctava_durata”, spre exemplu C4_3 ,unde C este nota, 4 este octava, 3 este durata.

Figura 6.2.3. –Rezultatul obținut sunt notele partiturii “happy_birthday” intr-o listă cu elemente de forma “notaoctava_durata”

Probele de sunet puse la dispoziție sunt fișiere de tip .wav, cu circa 7 secunde durată, câte unul pentru fiecare nota din gama Do major (C4,D4,E4,F4,G4,A4,B4,C5) , aceste fișiere trebuie trunchiate la dimensiunea corespunzătoare duratei fiecărei note. La final toate sunetele aferente notelor trebuie concatenate. Pentru a îndeplini acest lucru utilizăm modulul Pydub[87] care permite manipularea fișierelor audio .wav. Modulul Pydub conține funcțiile necesare pentru a prelucra fișierele de sunet date astfel încăt acestea sa corespundă notelor și duratelor identificate anterior.

Maparea este un proces de convertire dintr-un format al datelor într-un alt format, în cazul de față formarea de legături între un element al listei rezultate în figura 6.2.3. și un sunet prelucrat din cadrul probelor date. De exemplu elementului “F4_12” îi va corespunde sunetul Fa cu durata de „12”.

Pentru a da o înțelegere în secunde valorii „12” trebuie să observăm că nota F este o doime cu punct (.) Adăugând un punct la o nota, valoarea acesteia se mărește cu jumătate din valoarea inițială a notei. Așadar o doime are durata de “8”, deci o pătrime (♩) va avea o durată de “4” , cât reprezintă acest număr însă este la liberă alegere, ținând cont că măsura este 3/4 și având in vedere metrica cântecului. Deoarece o pătrime corespunde unei bătăi, considerăm ca o bătaie durează o secunda, deci 4=1s, în cazul în care rezultatul nu ne convine, putem aplica metoda acordării experimentale pentru a modifica timpul aferent duratelor astfel încăt rezultatul să fie mai bun. Pentru legăturile propriu-zise am folosit o funcție dicționar care face legătura între o notă+octavă și un fișier sunet, prezentată în imaginea următoare:

Figura 6.2.4. –Funcția dicționar din cadrul scriptului python mxml_script.py

Probele de sunet Voice011Voice018 corespund notelor din gama do major și sunt atribuite elementelor nota+octavă din lista din figura 6.2.3. Odată ce această legătură este facută, fișierul sunet este trunchiat în funcție de durată și concatenat lângă celelalte. Pentru a nu tranziționa brusc între note, se aplică o funcție fade aparținând tot modulului pydub: newAudio.fade_in(0.1).fade_out(0.1). Rezultatul este un fișier .wav ce conține cântecul dorit.

Următorul fragment de cod ne permite, prin utilizarea modulului Paramiko pentru a ne conecta via SFTP, să transferăm cântecul în format .wav în memoria lui NAO pentru a-l cânta prin comanda:aup.post.playfile(destination).

Figura 6.2.5. –Funcția necesară pentru a trimite și stoca un fișier în memoria lui NAO

Înregistrarea rezultatului poate fi accesată la https://youtu.be/idNa1B2mtdk (outdated, de actualizat), se poate observa că rezultatul obținut nu este foarte bun, dar se poate urmări linia melodică atunci când robotul recită “Happy Birthday” și se poate identifica cântecul chiar daca nu am cunoaște în prealabil ce este.

Scriptul mxml_script.py este utilizabil pentru orice partitură scrisă în cheia sol cu notele gamei do major salvată într-un format acceptat de Audiveris sau un fișier în format .xml ce respectă standardul MusicXML și conține doar notele gamei do major, cheia sol și nu prezintă alterații. Scriptul se poate generaliza și mai mult dacă se face reprezentarea sonoră a alterațiilor și a pauzelor din partitură în cadrul cântecului sau dacă se oferă mai multe probe de sunet pentru a extinde “baza de sunete” la care sunt mapate elementele identificate în partitură.

Modul Interpretare / Singing Mode

Modul Interpretare reprezintă scriptul al cărui rezultat este interpretarea vocală a unei partituri muzicale date prin intermediul unui sintetizator de voce. Intrarea va fi o partitură muzicală, iar rezultatul o melodie prelucrată de web service-ul sintetizatorului SinSy disponibil la www.sinsy.jp ce va fi trimisă către robot pentru a fi interpretată vocal.

Pentru convertirea partiturii scrise se utilizează la fel ca în cazul modului didactic, Audiveris. Fișierul .xml rezultat după dezarhivarea arhivei .mxl produsă de audiveris este trimis către sintetizator prin intermediul unui script auxiliar python, intitulat sinsy-cli[88], creat de Olivier Jolly în 2016. Același script se ocupă și de recuperarea fișierului de sunet .wav rezultat în urma prelucrării efectuate de sintetizator. Pentru a trimite rezultatul către NAO se procedează în același fel ca și în cadrul modului didactic prezentat în subcapitolul precedent.

Fig. 6.3.1. – Diagrama ce descrie firul de executie al modului interpretare

Scriptul dezvoltat, singing_module_script.py se ocupă de apelarea secvențială a Audiveris, dezarhivarea fișierului generat și trimiterea către sintetizator a fișierul .xml după introducerea în linia de comandă a parametrilor doriți, conform instrucțiunilor afișate.

Apelul către părțile terțe( Audiveris, 7 zip, sinsy-cli) se execută conform codului din imaginile următoare:

Figura 6.3.2. –Fragment de cod pentru rularea Audiveris și extragerea fișierului xml la destinația dorită

Figura 6.3.3. –Fragment de cod pentru introducerea parametrilor necesari Sinsy și apelarea comenzii de rulare pentru sinsy-cli

La rularea scriptului din cadrul meniului vor fi cerute anumite informații pentru execuția programului, acestea se introduc între ghilimele, de exemplu “.pdf”,”happy_birthday”, conform imaginii următoare care arată un input corect pentru execuția scriptului aferent modului interactiv.

Figura 6.3.4. –Exemplu de rulare a scriptului singing_module_script.py pornind de la un fișier .xml deja existent

Valorile recomandate pentru NAO sunt: voice_nr 4 sau 5, gender_parameter intre 0.55 și 0.62, vibrato_intensity 1, iar pentru pitch_shift valori intre -4 și 4. Se poate experimenta cu valorile parametrilor până la obținerea rezultatului preferat, de notat însă că valorile extreme pentru gender parameter și valorile mici pentru vibrato intensity pot duce la rezultate inaudibile sau care conțin zgomot.

Transferul fișierului rezultat către robotul NAO pentru a fi interpretat se realizează la fel ca în cadrul scriptului descris în subcapitolul precedent, imaginea următoare prezintă funcția dezvoltată în acest scop:

Figura 6.3.5. – Funcția necesară pentru a trimite și stoca fișierul rezultat în memoria lui NAO

Un exemplu în care NAO interpretează un cântec generat din rularea scriptului se poate asculta la https://www.youtube.com/watch?v=0QM6mr0wM8I (outdated, de actualizat).

Modul Toboșar / Drum Playing Mode

<de redactat>

Recunoașterea vorbirii / Speech Recognition

În cadrul acestui script ne vom concentra pe obținerea unui mod propice de comunicare între om și robot, dialogul între aceștia fiind facilitat de un sistem de recunoaștere a vorbirii (speech recognition) și îmbogățită prin utilizarea gesturilor de către robot. Pentru o interacțiune om-robot cât mai fidelă și mai naturală –prin naturală înțelegem cât mai apropiată de interacțiunea între ființe vii , se dorește implementarea unui mod prin care robotul să identifice limbajul natural ce ii este adresat și să răspundă corespunzător la întâlnirea acestuia. Astfel, pe baza sunetului captat de microfoanele robotului, acesta va trebui să sintetizeze mesajul – procedeu intitulat ASR (Automatic Speech Recognition) sau STT(Speech to Text), iar pe baza rezultatului receptionat să acționeze corespunzător, de exemplu : răspunsul la salut.

Modul în care serviciul Wit.AI, prezentat în subcapitolul 5.6, va fi utilizat este următorul: se vor trimite inregistrările unuia din microfoanele robotului NAO (cel care are cel mai puțin zgomot de fundal) către aplicația wit găzduită în cloud și limbajul vocal va fi transformat în text, prin antrenarea aplicației se vor obține rezultate din ce in ce mai precise, obținându-se rata de încredere dorită pentru ca mesajele vocale transmise să fie înțelese corect în majoritatea cazurilor.

Figura 6.5.1. –Diagrama ce descrie firul de execuție al activităților implementate în cadrul scriptului

Modul în care serviciul funcționează pentru speech-to-text este următorul: se oferă un server access token ce permite accesul la aplicația creată online

Figura 6.5.2. –Tokenul de access la wit.ai

Acest token se utilizează în scriptul creat in Python pentru a ne autentifica la server și pentru a urca probele de sunet înregistrate de unul din microfoanele robotului NAO, în urma prelucrării acestei probe de sunet se primește înapoi un mesaj ce conține textul perceput din înregistrarea primită.

Fig. 6.5.3. – Stabilirea legăturii dintre scriptul Python și serviciul Wit.ai folosind tokenul dat

Fiecare răspuns al serviciului poate fi validat sau, daca este greșit sau nu corespunde cu ceea ce s-a transmis, corectat de către utilizator în scopul antrenării rețelei neurale. Cu cât există mai multe validări, cu atât crește rata de încredere pentru răspunsul așteptat. De asemenea este de preferat ca înregistrările audio să fie diverse, cu tonalitate diferită sau voci diferite, pentru a perfecționa astfel serviciul.

Figura 6.5.4. –Funcția ce se ocupă de trimiterea fișierului înregistrat către serviciul Wit.ai

Pentru a testa compatibilitatea dintre robotul NAO și aplicația de speech-to-text ce comunică cu serverul Wit.ai am creat scriptul Nao_Wit_Speech.py în cadrul căreia NAO înregistrează ceea ce spune utilizatorul, trimite înregistrarea către serviciul Wit și recuperează informațiile sub o formă interpretabilă.

S-a dezvoltat scriptul Nao_Wit_Speech.py pentru a testa capabilitățile sistemului de recunoaștere a vorbirii.

Funcționalitatea scriptului de testare este următoarea:

În funcție de valoarea primită de switchKey, aplicația va funcționa într-unul din cele două moduri de testare.

Dacă switchKey =1 , la rularea scriptului se va auzi sunetul de start al înregistrării, utilizatorul uman este rugat să transmită robotului un mesaj în limba engleză, după auzul sunetului de stop al înregistrării, acest mesaj va fi trimis către serviciul Wit pentru transpunere în text prin intermediul scriptului Nao_Wit_Speech.py iar ulterior întors înapoi, dacă în cadrul mesajului s-au putut identifica cuvintele “hello”, “goodbye” sau “sorry”, robotul NAO va răspunde corespunzător printr-un anunț vocal și un gest specific.

Dacă switchKey =2 , după rularea scriptului se va auzi sunetul de start al înregistrarii,, utilizatorul uman este rugat să transmită robotului un mesaj în limba engleză, după auzul sunetului de stop al înregistrării, mesajul va fi transmis către serviciul Wit pentru transpunere în text, iar ulterior trimis înapoi. Robotul NAO va încerca să imite ceea ce a zis utilizatorul, prin citirea mesajului recepționat din Cloud, de asemenea dacă se va simti insultat, robotul va răspunde acestui lucru.

Înregistrarea de la https://youtu.be/2MfptXMyaFM prezintă efectuarea celor două teste.

Se recomandă accesarea serviciului online după efectuarea testelor și validarea funcționalității corecte sau corectarea funcționalității gresite, pentru a îmbunătății sistemul de recunoaștere a vorbirii și a îl putea folosi în permanență în cadrul interacțiunii pentru a oferi comenzi vocale de accesare a celorlalte aplicații utilizate în cadrul realizării practice.

Figura 6.5.5. –NAO facând un gest specific în urma unei propoziții pe care nu a putut s-o coreleze cu “hello” “goodbye” sau “sorry”

Joc 2d: Ferește-te NAO, ferește-te! / Dodge NAO, dodge!

Jocul creat în pygame este foarte simplu și se bazează pe următoarele reguli :

NAO se poate mișca pe ecran doar stânga/dreapta

atingerea marginii stângi sau drepte a suprafeței de joc va duce la finalul jocului

din partea superioară a ecranului vor cădea atât note muzicale cât și un bloc de culoare neagră

contactul dintre NAO și un bloc negru va duce la finalul jocului.

Fiecare notă muzicală atinsă de NAO va crește scorul cu un punct, fiecare bloc negru care ajunge în partea de jos a suprafeței de joc fără a-l atinge pe NAO crește scorul cu un punct.

Atentie! Blocul negru va deveni din ce în ce mai rapid la fiecare coborâre.

Obiectivul este să te menții cât mai mult în joc și să obții un scor cât mai mare.

Figura 6.6.1 –Imagine din jocul aplicației, Dodge NAO, dodge!

Figura 6.6.2. – Exemple de funcții utilizate în codul jocului, prima funcție se ocupă cu desenarea blocului negru și redesenarea acestuia pe suprafața de joc, iar cea de-a doua implementează regula de coliziune între două obiecte (NAO și un bloc negru sau NAO și o notă muzicală).

Îmbunătățiri și alte potențiale aplicații în cadrul interacțiunii

Concluzii

Bibliografie

[1] The History of Computing Project, “Timeline of Robotics”, https://www.thocp.net/reference/robotics/robotics.html , Accesat 03 Septembrie 2018

[2] RobotShop Distribution Inc., “History of Robotics: Timeline,” Robot. Distrib. Inc., p. 11, 2008.

[3] „Historical Automata”, http://www.contemporaryautomata.com/history.html, Accesat 03 Septembrie 2018

[4] The Popular Appeal of Machinery, http://www4.ncsu.edu/~kimler/hi322/automata.html Accesat 03 Septembrie 2018

[5] Webster’s Seventh New Collegiate Dictionary. 1966, Springfield, Massachusetts: G. and C. Merriam Company , sau https://www.merriam-webster.com/dictionary/robot , Accesat 03 Septembrie 2018

[6] Nillson, N.,” Shakey the Robot”, SRI AI Center Technical Note, 1984

[7] SRI International, “Shakey the Robot”, https://www.sri.com/work/timeline-innovation/timeline.php?timeline=computing-digital#!&innovation=shakey-the-robot, Accesat 03 Septembrie 2018

[8] Yamaoka, F., Kanda, T., Ishiguro, H., and Hagita, N., “Lifelike” Behavior of Communication Robots Based on Developmental Psychology Findings, in IEEE-RAS International Conference on Humanoid Robots. 2005.

[9] Gockley, R., Forlizzi, J., and Simmons, R., Natural Person-Following Behavior for Social Robots, in ACM/IEEE International Conference on Human-Robot Interaction. 2007.

[10] A. Lucia, S. A. Moga, A. L. Păiș, S. A. Moga, and C. Buiu, “Emotions and Robot Artists : State-of-the-Art and Research Challenges,” Bul. Univ. Pet. – Gaze din Ploiești, vol. LXII, no. 1, pp. 26–40, 2010.

[11] C. Buiu and N. Popescu, “Aesthetic emotions in human-robot interaction. Implications on interaction design of robotic artists,” Int. J. Innov. Comput. Inf. Control, vol. 7, no. 3, pp. 1097–1107, 2011.

[12] Walters, M.L., Dautenhahn, K., Woods, S. N., and Kheng Lee Koay, Robot Etiquette: Results from User Studies Involving a Fetch and Carry Task, in ACM/IEEE International Conference on Human-Robot Interaction. 2007.

[13] K. Dautenhahn, “Socially intelligent robots: dimensions of human-robot interaction.,” Philos. Trans. R. Soc. Lond. B. Biol. Sci., vol. 362, no. 1480, pp. 679–704, 2007.

[14] Y. Nguyen, M. Miroir, G. Kazmitcheff, E. Ferrary, O. Sterkers, and a. B. Grayeli, “From Conception to Application of a Tele-Operated Assistance Robot for Middle Ear Surgery,” Surg. Innov., vol. 19, no. 3, pp. 241–251, 2012.

[15] L. Kovacs, T. Haidegger, and I. Rudas, “Surgery from a distance—Application of intelligent control for telemedicine,” Appl. Mach. Intell. Informatics (SAMI), 2013 IEEE 11th Int. Symp., pp. 125–129, 2013.

[16] D. Aschenbrenner, M. Fritscher, F. Sittner, M. Krauß, and K. Schilling, “Teleoperation of an industrial robot in an active production line,” IFAC-PapersOnLine, vol. 28, no. 10, pp. 159–164, 2015.

[17] IEEE International Symposium on Robot & Human Interactive Communication 2017 ,http://www.ro-man2017.org/site/, Accesat 03 Septembrie 2018

[18] IEEE-RAS International Conference on Humanoid Robots, http://www.humanoids2016.org/ , Accesat 03 Septembrie 2018

[19] The Twelfth Annual Conference on Human-Robot Interaction (HRI 2017) http://humanrobotinteraction.org/2017/, Accesat 03 Septembrie 2018

[20] SPARC, “Robotics 2020 Multi-Annual Roadmap,” vol. 2016, p. 325, 2016.

[21] E. Bizzi, S. Lemaignan, A. Jacq, and D. et a Hood, “Learning By Teaching a Robot,” vol. 93, no. April, pp. 3843–3846, 1996.

[22] M. A. Goodrich and A. C. Schultz, Human–Robot Interaction: A Survey, Foundation and Trends in Human–Computer Interaction, vol 1, no 3, pp 203–275, 2007

[23] E. Noveanu, “Metacognitie”, http://inovatie.numeris.com.ro/E.Noveanu-Metacognitie.pdf , Accesat 03 Septembrie 2018

[24] T. Varnado et al, “Using Robotics Education to Improve Problem Solving Skills, Metacognition, and Self-efficacy”, North Carolina State University, Raleigh,NC,USA , 2014

[25] Fujitsu Laboratories, Service robot “enon”, http://mindtrans.narod.ru/pdfs/fujitsu-labs-robotics-006-en.pdf, Accesat 03 Septembrie 2018

[26] “NAO Robot Plays Tic-Tac-Toe Board Game against Human” https://www.youtube.com/watch?v=1xBh2LkGJX8 , Accesat 03 Septembrie 2018

[27] CNN, ”Robot teachers invade South Korean Classrooms”, http://edition.cnn.com/2010/TECH/innovation/10/22/south.korea.robot.teachers/, Accesat 03 Septembrie 2018

[28] Softbank Robotics, “Meet Connie, Hilton Hotel’s First Robot Concierge” https://developer.softbankrobotics.com/us-en/showcase/nao-ibm-create-new-hilton-concierge , Accesat 03 Septembrie 2018

[29] Kosuge, K. et al. “Dance Partner Robots — Ms. DancerR”, in IEEE/RSH International Conference on Intelligent Robots and Systems. 2003: Las Vegas, Nevada, USA.

[30] ”Robot Pianist Teo Tronico “live” at Berlin Philarmonie”, https://www.youtube.com/watch?v=U5rKjrQ3JoE, Accesat 03 Septembrie 2018

[31] Toyota Motor Corporation, “Toyota Partner Robots”, http://www.toyota.co.jp/en/news/04/1203_1d.html, Accesat 03 Septembrie 2018

[32] Blitch, J.G., “Artificial Intelligence Technologies for Robot Assisted Urban Search and Rescue.” Expert Systems with Applications, 1996. 11(2): p. 109-124.

[33] Jacoff, A., Messina, E., and Evans, J., “A Standard Test Course for Urban Search and Rescue Robots”, in Performance Metrics for Intelligent Systems. 2000: Gaithersburg, Maryland, USA.

[34] V. N. Salimpoor, M. Benovoy, K. Larcher, A. Dagher, and R. J. Zatorre, “Anatomically distinct dopamine release during anticipation and experience of peak emotion to music.,” Nat. Neurosci., vol. 14, no. 2, pp. 257–62, 2011.

[35] K. Suh, “Using NAO: Introduction to interactive humanoid robots”, France, Aldebaran Robotics & NT Research Inc., pp 9-275, 2013.

[36] M. Fridin and M. Belokopytov, “Acceptance of socially assistive humanoid robot by preschool and elementary school teachers,” Comput. Human Behav., vol. 33, pp. 23–31, 2014.

[37] M. Fridin, H. Angel, and S. Azery, “Acceptance , Interaction , and Authority of Educational Robots : An ethnography study of child-robot interaction,” Most, pp. 1–4, 2011.

[38] B. Robins, K. Dautenhahn, and J. Dubowski, “Does appearance matter in the interaction of children with autism with a humanoid robot?,” Interact. Stud., vol. 7, no. 3, pp. 509–542, 2006.

[39] A. Taheri, A. Meghdari, M. Alemi, and H. Pouretemad, “Social Robotics,” vol. 8239, no. October 2013, pp. 2–3, 2013.

[40] GARS Evaluation Template, available for download at https://www.lcsc.org/cms/lib6/…/EvaluationTemplateGilliamAutismRatingScale2.doc, Accesat 05 Septembrie 2018

[41] N. A. Malik, H. Yussof, F. A. Hanapiah, R. A. A. Rahman, and H. H. Basri, “Human-Robot Interaction for Children with Cerebral Palsy: Reflection and Suggestion for Interactive Scenario Design,” Procedia Comput. Sci., vol. 76, no. Iris, pp. 388–393, 2015.

[42] V. Pîrvu, “Interactiunea cu un robot umanoid folosind gesturi naturale”,Bachelor Thesis, Polytechnic University of Bucharest, Faculty of Automatic Control and Computer Science, Bucharest, September 2016

[43] A. Mocanu, “Comanda unui robot NAO utilizând gesturi ale mâinii” ,Bachelor Thesis, Polytechnic University of Bucharest, Faculty of Automatic Control and Computer Science, Bucharest, September 2016

[44] R. Ros, I. Baroni, and Y. Demiris, “Adaptive human–robot interaction in sensorimotor task instruction: From human to robot dance tutors,” Rob. Auton. Syst., vol. 62, no. 6, pp. 707–720, 2014.

[45] T. Belpaeme, P. Baxter, et al, “Multimodal Child-Robot Interaction: Building Social Bonds,” J. Human-Robot Interact., vol. 1, no. 2, pp. 33–53, 2012.

[46] Avram Florea, “Educație muzicală și didactica muzicii”, Ministerul educației și cercetării, Proiectul pentru învățământul Rural, 2007, ISBN 978-973-0-05179-7

[47] Avram Florea, “Educație muzicală – teorie și solfegii aplicative”, Timișoara, Editura
Universității de Vest, 2006, ISBN 973-7608-70-4

[48] A. Rebelo, I. Fujinaga, F. Paszkiewicz, A. R. S. Marcal, C. Guedes, and J. S. Cardoso, “Optical music recognition: state-of-the-art and open issues,” Int. J. Multimed. Inf. Retr., vol. 1, no. 3, pp. 173–190, 2012.

[49] SmartScore, https://www.musitek.com/smartscore-pro.html, Accesat 03 Septembrie 2018

[50] SharpEye, http://www.visiv.co.uk/, Accesat 03 Septembrie 2018

[51] CapellaScan, https://www.capella-software.com/us/index.cfm/products/capella-scan/info-capella-scan/, Accesat 03 Septembrie 2018

[52] OpenOMR, https://sourceforge.net/projects/openomr/files/ , Accesat 03 Septembrie 2018

[53] Audiveris, https://github.com/audiveris, Accesat 03 Septembrie 2018

[54] Gamera, https://gamera.informatik.hsnr.de/, Accesat 03 Septembrie 2018

[55] Audiveris Wiki , https://github.com/Audiveris/audiveris/wiki/, Accesat 03 Septembrie 2018

[56] TesseractOCR, https://github.com/tesseract-ocr, Accesat 03 Septembrie 2018

[57] DeepLearning4J, https://deeplearning4j.org/, Accesat 03 Septembrie 2018

[58] MusicXML, http://www.musicxml.com/, Accesat 03 Septembrie 2018

[59] Finale, https://www.finalemusic.com/, Accesat 03 Septembrie 2018

[60] What is MusicXML?, http://usermanuals.musicxml.com/MusicXML/MusicXML.htm, Accesat 03 Septembrie 2018

[61] Lista de Software ce utilizează MusicXML, http://www.musicxml.com/software/, Accesat 03 Septembrie 2018

[62] Sibelius, http://www.avid.com/sibelius, accesat Accesat 03 Septembrie 2018

[63] E. Nichols, D. Morris, S. Basu, and C. Raphael, “Relationships between lyrics and melody in popular music”, ISMIR 2009

[64] Relationships Between Lyrics and Melody in Popular Music Supplementary material http://music.informatics.indiana.edu/code/musicxml/, Accesat 03 Septembrie 2018

[65] Vocaloid, http://www.vocaloid.com/, Accesat 03 Septembrie 2018

[66] SinSy, http://sinsy.sourceforge.net/ , Accesat 03 Septembrie 2018

[67] SinSy web service, http://www.sinsy.jp/, Accesat 03 Septembrie 2018

[68] HMM/DNN-based Speech Synthesis System(HTS), http://hts.sp.nitech.ac.jp/, Accesat 03 Septembrie 2018

[69] Hidden Markov Model Toolkit (HTK) , http://htk.eng.cam.ac.uk/ , Accesat 03 Septembrie 2018

[70] Oxford Dictionaries, https://en.oxforddictionaries.com/ , Accesat 03 Septembrie 2018

[71] A. Graves, S. Fernandez, F. Gomez, and J. Schmidhuber, “Connectionist Temporal Classification: Labelling Unsegmented Sequence Data with Recurrent Neural Networks,” Proc. 23rd Int. Conf. Mach. Learn., pp. 369–376, 2006.

[72] L. Rabiner and B.-H. Juang, “An introduction to hidden markov models,” ASSP Magazine, IEEE, vol. 3, no. 1, pp. 4–16, 1986.

[73] M. Gales and S. Young, “The Application of Hidden Markov Models in Speech Recognition,” Found. Trends® Signal Process., vol. 1, no. 3, pp. 195–304, 2007.

[74] S. Haykin, „Neural Networks. A Comprehensive Foundation”,Macmillan College Publishing Company, N.Y., 1994.

[75] T.Ebermann, “Speech recognition with wit.ai”, https://www.liip.ch/en/blog/speech-recognition-with-wit-ai, Accesat 04 Septembrie 2018

[76] S. Cook, “Speech Recognition HOWTO,” p. 20, 2002. https://www.tldp.org/HOWTO/pdf/Speech-Recognition-HOWTO.pdf, Accesat 04 Septembrie 2018

[77] API.ai, https://dialogflow.com/ , Accesat 04 Septembrie 2018

[78] Wit.ai, https://wit.ai/ , Accesat 04 Septembrie 2018

[79] IBM Watson Speech-to-Text, https://www.ibm.com/watson/services/speech-to-text/, a Accesat 04 Septembrie 2018

[80] Microsoft LUIS, https://www.luis.ai/home , Accesat 04 Septembrie 2018

[81] Amazon Alexa, https://developer.amazon.com/alexa-skills-kit/asr , Accesat 04 Septembrie 2018

[82] Sphinx, http://www.speech.cs.cmu.edu/sphinx/doc/Sphinx.html , Accesat 04 Septembrie 2018

[83] Mycroft STT, https://openstt.org/ , Accesat 04 Septembrie 2018

[84] Kaldi ASR, https://github.com/kaldi-asr/kaldi , Accesat 04 Septembrie 2018

[85] Mozilla DeepSpeech, https://github.com/mozilla/DeepSpeech/wiki , Accesat 04 Septembrie 2018

[86] Documentație xml.dom.minidom, https://docs.python.org/2/library/xml.dom.minidom.html, Accesat 04 Septembrie 2018

[87] Pydub AudioSegment python module, http://pydub.com/, Accesat 05 Septembrie 2018

[88] Sinsy_cli script, https://pypi.python.org/pypi/sinsy-cli/0.5.0, Accesat 05 Septembrie 2018