Aplicatia Mobila Flexirc

Cuprins

1. Introducere

1.1. Generalități

1.2. Descrierea proiectului

2. Fundamentare teoretică

2.1. Sistemul de teleghidare

2.2. Android

2.3. Android SDK

2.4. Bluetooth

2.5. Atmel SAM D20 Xplained Pro

2.6. Atmel Studio 6

2.7. Lynxmotion 4WD1 Rover

2.8. Sabertooth 2x12RC

3. Specificațiile proiectului

3.1. Aplicația mobile – FlexiRC

3.1.1. Diagrama use case

3.1.2. Modul de utilizare

3.2. Protocolul de comunicare

3.3. Vehiculul

4. Proiectare și implementare

4.1. Arhitectura aplicației FlexiRC

4.2. Comportamentul dinamic al aplicației FlexiRC

4.3. Arhitectura software a vehiculului

4.3.1. Nivelul driver

4.3.2. Nivelul aplicație

4.4. Comportamentul dinamic al software-ului vehiculului

4.4.1. Secvența de inițializare a software-ului vehicului

4.4.2. Secvența de recepție a comenzilor

4.4.3. Secvența de comandă a motoarelor

4.5. Mediul de dezvoltare

Introducere

Generalități

Ingineria este, încă din antichitate, unul dintre principalii piloni ai dezvoltării continue a civilizației. Aceasta are ca scop aplicarea cunoștiințelor științifice, economice și sociale în soluționarea numeroaselor provocări apărute în încercarea de a îmbunătăți modul în care oamenii trăiesc și interacționează cu mediul înconjurător.

Una dintre provocările fundamentale ale ingineriei este introducerea unor mijoace tehnice care să preia anumite sarcini atribuite în trecut animalelor, persoanelor sau grupurilor de persoane. Motivele pot varia în funcție de domeniul și natura sarcinii. De exemplu, introducerea autovehiculelor în transporturi sau a roboților industriali și a proceselor automate în linii de asamblare au permis creșterea productivității și evitarea muncilor solicitante fizic sau de rutină.

O altă provocare apărută în numeroase domenii este comuncația practică pe distanțe mari (telecomunicația). Primele soluții practice au constat în tehnologii de transmisie vizuală (semnale cu fum, heliografe) sau auditivă(tobe, trâmbițe, goarne). Telecomunicațiile moderne au luat naștere o dată cu apariția primelor soluții bazate pe tehnologii electrice(telegraf) și electromagnetice(radio), la sfârșitul secolului al VIII-lea și culminând cu tehnologii precum televiziunea, fibra optică, sateliții de comunicație și internet-ul.

O consecință particulară a telecomunicațiilor este dezvoltarea capacității de a opera un sistem de la distanță, adică de a-l teleghida, permițând astfel accesul uman indirect în medii de lucru periculoase sau inaccesibile.

Primele sisteme teleghidate au apărut din nevoia de a manipula materiale periculoase în siguranță, de la distanță. Pe măsură ce sistemele au evoluat și distanța s-a mărit, au apărut două probleme noi: observarea directă nu mai era posibilă pentru operator și apariția întârzierilor cauzate de distanță. Prima problemă a fost adresată utilizând sisteme video. Pentru a doua problemă, strategia abordată a fost descompunerea sarcinilor în operații atomice, care puteau fi transmise. Acest lucru a dus la dezvoltarea așa-numitului control de supervizare, o abordare ce permitea operatorului să specifice sarcini la nivel înalt, dar care să fie descompuse atomic și transmise de sistemul de comandă.

O dată cu soluționarea acestor probleme, următorul obiectiv formulat a în evoluția sistemelor teleghidate a fost atingerea, așa numitei, tele-prezență. Aceasta presupune ascunderea interfeței și permiterea operatorului să execute interacțiuni în modul în care le-ar executa dacă ar fi prezent fizic în mediul de lucru. Pe de o parte, interfața om-mașină trebuie să permită achiziția corectă a tuturor dorințelor de comandă a operatorului uman și să le transmită la sistemul comandat. Pe de altă parte, sistemul comandat trebuie să achiziționeze o „imagine” cât mai completă a mediului de lucru și să o translateze în stimuli pentru operatorul uman, permițându-i să „se simtă” în acel mediu. În prezent, tele-prezența este un model teoretic, punerea sa în practică fiind limitată, în funcție de aplicație, de tehnologie sau de mediul de lucru.

Aplicațiile sistemelor teleghidate sunt foarte variate și au o răspândire într-un spectru foarte larg de domenii. În medicina chirurgicală, de exemplu, utilizarea teleroboților, precum sistemul daVinci, permit proceduri chirurgicale cu invazivitate minimă. Un alt exemplu este domeniul militar, în care sistemele teleghidate sunt prezente în drone (vehicule aeriene teleghidate, de exemplu MQ-9 Reaper) utilizate în misiuni de supraveghere sau roboți tereștri folosiți în misiuni de detectare și dezamorsare a bombelor artizanale, evitând astfel riscul pierderii de vieți umane. În domeniul științific, sistemele teleghidate sunt utilizate într-o gamă foarte variată de medii, de la vehicule submersibile utilizate în explorarea celor mai adânci porțiuni ale oceanelor(Nereus), până la roboți de tip rover folosiți în explorarea altor planete(Curiosity).

Pe lângă acestea, sistemele teleghidate stau la baza modelismului, o activitate tehnico-aplicativă, având ca obiect construirea și pilotarea modelelor la scară redusă. În funcție de tipul modelului, modelismul se împarte în automodelism, aeromodelism și navomodelism. Teleghidarea se face prin intermediul radiocomenzilor, care comunică cu modelul prin unde radio în banda de frecvențe 2.4-2.5 GHz.

Odată cu dezvoltarea sistemelor mobile din ultimii ani, a apărut posibilitatea creării aplicațiilor mobile care, utilizând diverse tehnologii (Bluetooth, GSM/GPRS), să poată comanda diverse sisteme la distanță, de la echipamente multimedia, la sisteme de securitate sau automodele.

Descrierea proiectului

Lucrarea de față își propune să fie o prezentare a modului în care se poate proiecta și implementa un sistem simplu de teleghidare al unui vehicul de tip rover, comandat cu un dispozitiv mobile, utilizând o varietate de tehnologii hardware și software pentru diversele componente ale sistemului. Motivația principală în spatele temei alese o reprezintă lipsa unei aplicații mobile de teleghidare a unui vehicul care să ofere o interfață cu utilizatorul adaptabilă, în funcție de tipul vehiculului și preferințele utilizatorului.

Astfel, proiectul tratează două componente. Pe de o parte, sunt abordate problemele de dezvoltare a aplicației mobile, de la proiectarea diverselor interfețe cu utilizatorul, până la asigurarea comunicării fiabile și în timp real cu vehiculul. Pe de altă parte, este problematica proiectării și implementării unui sistem încorporat care să preia comenzile, să le prelucreze, și să le transpună în semnale de control a motoarelor unui vehicul.

Deși aplicația de comandă este proiectată să ofere utilizatorului posibilitatea de a comanda mai multe tipuri de vehicul, sistemul comandat este un caz particular, și anume un vehicul terestru de tip rover, având mecanism de direcție bazat pe diferența de rotație a roților de pe cele două părți a acestuia, similar vehiculelor cu șenile.

Fundamentare teoretică

Sistemul de teleghidare

Teleghidarea reprezintă procesul de comandare a unui dispozitiv aflat la distanță față de operator. Un sistem de teleghidare este un sistem format din următoarele componente: operator, telecomandă, canal de comunicație, dispozitiv comandat. Astfel, operatorul reprezintă persoana care comandă sistemul. Telecomanda reprezintă dispozitivul de interfațare cu operatorul și are rolul de a prelua comenzile de la acesta și de a le transmite pe canalul de comunicație. Dispozitivul comandat se află în mediul de lucru, și are rolul de a executa comenzile primite de la operator. Dacă sistemul de teleghidare permite control în timp real(întârzierile cauzate de distanța dintre operatorul uman și dispozitivul comandat sunt neglijabile), se poate vorbi de un sistem cu buclă închisă, dacă operatorul controlează actuatoarele dispozitivului comandat prin semnale directe (analogice) și primește de la acesta reacție în timp real. În figura 2.1 este ilustrat modelul unui sistem de teleghidare cu buclă închisă.

Fig. 2.1. Sistem de teleghidare cu buclă închisă

Android

Pentru dezvoltarea aplicației mobile pentru telecomandă, a fost nevoie nevoie alegerea unui sistem de operare flexibil, care să ofere acces la componentele hardware ale sistemului mobile. Din aceste motive, sistemul de operare ales este sistemul Android.

Android este una din cele mai populare platforme software și sistem de operare pentru telefoane mobile inteligente din lume. Cu ajutorul Android se pot accesa peste un milion de aplicații și jocuri disponibile în Google Play. Sistemul de operare Android poate să fie instalat pe telefoane mobile inteligente de ultimă generație și dispune de o multitudine de funcționalități. De la înființare și până în anul 2012 numărul de dispozitive pe care ruleaza acest sistem de operare a depășit cifra de 400 de milioane în mai mult de 190 de țări, ajungând în prezent la aproximativ un miliard de utilizatori. Este cel mai utilizat sistem de operare pentru dispozitivele mobile de tip smartphone. De asemenea platforma Android este accesibilă oricărui dezvoltator pentru a crea aplicații și a le publica pentru utilizare.

Sistemul de operare Android este bazat pe versiunea Linux 2.6 pentru servicii ale sistemului, gestionarea memoriei, securitatea, stiva de rețea și procesul de management. Începând cu anul 2008 Android este disponibil ca Open Source și astfel codul sursă este disponibil tuturor celor care vor sa dezvolte aplicații. Un set complet de instrumente de dezvoltare sunt incluse cu acest scop în SDK-ul Android și sunt disponibile pe site-ul oficial. Cei care dezvoltă aplicații pe această platformă au acces la API-urile folosite de aplicațiile bază, la utilizarea modulului de bluetooth, modului wireless, transmiterea mesajelor și apelarea cu ajutorul moduluilui GSM, utilizarea accelerometrului, a difuzorului sau a funcției de vibrare. În prezent ultima versiune este Android 4.4(nivel API 19), denumit KitKat.

Platforma Android pune la dispoziție utilizatorilor posibilitatea utilizării widget-urilor pentru o mai ușoara acesibilitate la serviciile de mail, informațiilor privind starea vremii sau a pozelor favorite. Notificările sunt un alt beneficiu major prin care utilizatorul este înștiințat despre apelurile telefonice, mesajele scrise, noile mailuri sau diferite informații utile transmise spre vizualizare de către aplicațiile care rulează. De asemenea o importantă facilitate de care dispune sistemul de operare Android este acela de a rula în paralel mai multe aplicații cu posibilitatea schimbării în orice moment al aplicației în care se lucrează într-un moment. Recunoașterea feței și sincronizarea cu alte dispozitive care utilizează Android sunt ultimele beneficii nou aduse de către dezvoltatori.

Aplicațiile dezvoltate pentru Android dispun de diferite momente în care pot să execute prin intermediul metodelor specifice (onCreate(), onStart(), onResume(), onPause(), onStop, onRestart() și onDestroy()) funcționalități dezvoltate de către programator.

Metoda onCreate() se apelează în momentul în care fereastra se crează și aici se pot inițializa variabilele. Metoda onPause() este apelată atunci când aplicația este pusă în spate dar nu a fost închisă și o alta activitate este executată (datorită facilității de utilizare a mai multur aplicații în același timp). Atunci când se revine la aplicație se apelează onResume(). onDestroy() este metoda de care se poate folosi un dezvoltator de aplicații Android pentru a șterge toate datele care nu mai sunt necesare sau pentru a trimite ultimele detalii înainte ca aplicația să fie închisă și astfel memoria este eliberată.

Android SDK

Android SDK este un kit de dezvoltare software pentru aplicații Android, ce pune la dispoziție bibliotecile API și numeroase unelte pentru dezvoltarea și testarea acestora. Acest set include program special de depanare, un emulator de dispozitive Android, tutoriale, mostre de cod și documentații.

Android SDK are la bază Eclipse, un mediu de dezvoltare integrat împreliza variabilele. Metoda onPause() este apelată atunci când aplicația este pusă în spate dar nu a fost închisă și o alta activitate este executată (datorită facilității de utilizare a mai multur aplicații în același timp). Atunci când se revine la aplicație se apelează onResume(). onDestroy() este metoda de care se poate folosi un dezvoltator de aplicații Android pentru a șterge toate datele care nu mai sunt necesare sau pentru a trimite ultimele detalii înainte ca aplicația să fie închisă și astfel memoria este eliberată.

Android SDK

Android SDK este un kit de dezvoltare software pentru aplicații Android, ce pune la dispoziție bibliotecile API și numeroase unelte pentru dezvoltarea și testarea acestora. Acest set include program special de depanare, un emulator de dispozitive Android, tutoriale, mostre de cod și documentații.

Android SDK are la bază Eclipse, un mediu de dezvoltare integrat împreună cu plug-in-ul Android Development Tools.

Toate aplicațiile Android sunt dezvoltate folosind limbajul de programare orientat pe obiecte Java, pentru partea de funcționalitate, și meta-limbajul de marcare XML pentru definirea interfeței cu utilizatorul.

Depanarea aplicațiilor se poate face fie prin emulatorul pus la dispoziție de Android SDK, fie conectând un dispozitiv mobile fizic ce folosește sistemul Android.

Bluetooth

Bluetooth reprezintă un standard de tehnologie de comunicație fără fir, utilizat pentru schimbul de date pe distanțe scurte. Acesta este folosit într-o gamă foarte largă de dispozitive, de la sisteme mobile și computere, la echipamente medicale și sisteme multimedia.

Bluetooth operează în banda de frecvențe radio de 2400-2483,5 MHz. Datele transmise sunt împărțite pe pachete și fiecare pachet este transmis pe unul ditnre cele 79 de canale Bluetooth.

Protocolul de comunicație Bluetooth a fost standardizat sub forma standardului IEEE 802.1.15.1, însă în prezent acest standard nu mai este menținut. Bluetooth este un protocol pe bază de pachete, pe modelul master-slave. Un dispozitiv master poate comunica cu până la șapte dispozitive slave.

Raza de acțiune variază în funcție de specificul aplicației, și în funcție de clasa de transmițător radio. Transmițătoarele de clasă 3 au o rază de până la 1m distanță, cele de clasă 2 au o rază de aproximativ 10m, iar transmițătoarele de clasă 1 au raza de acțiune de până la 100m. Majoritatea sistemelor mobile folosesc transmițătoare radio de clasă 2 pentru Bluetooth. Rata de transfer variază între 1-3 Mbit/s.

Spre deosebire de alte tehnologii de comunicație fără fir, Bluetooth a fost conceput pentru un consum de energie electrică foarte scăzut. Un Dispozitiv Bluetooth de clasa 2, de exemplu, consumă 2.5mW. Pentru dispozitive care au un necesar foarte strict în privința consumului, a fost concepută tehnologia Bluetooth LE, având raza de 100m, dar cu un consum maxim de 10mW, comparat cu 100mW, în cazul unui transmițător de clasă 1.

Atmel SAM D20 Xplained Pro

Atmel SAM D20 Xplained Pro (figura 2.2) este o platformă hardware utilizată pentru dezvoltarea proiectelor bazate pe ATSAMD20J18A, un microcontroler de tip ARM Cortex-M0+, cu o frecvență de lucru de 48MHz.

Acest kit oferă acces ușor la la dispozitivele periferice ale microcontrolerului, prin intermediul pinilor grupați în 3 header-e.

Microcontrolerul ATSAMD20J18A oferă numeroase funcționalități, fiind potrivit pentru dezvoltarea unei game largi de aplicații încorporate. Funcționalitățile oferite sunt:

256kB memorie Flash programabilă

32kB memorie SRAM

Sistem de evenimente pe 8 canale,

Controler de întrruperi externe

16 întreruperi externe

O întrerupere nemascabilă

52 pini intrare-ieșire programabili

8 unități contor/temporizator pe 16 biți

6 module de comunicare serială, putând fi configurate ca USART, SPI și I2C

Un convertor analog-numeric pe 12 biți, cu până la 20 de canale

Tensiune de funcținoare între 1,62V-3,63V

În cadrul kitului Atmel SAM D20 Xplained Pro, cei 52 pini de intrare-ieșire sunt grupați în 3 header-e, permițând conectarea unor module de extensie:

OLED1 Xplained Pro – afișaj OLED 128×32 pixeli, 3 LED-uri și 3 butoane

ATmega256RFR2 ZigBit

I/O1 Xplained Pro – senzor de temperatură, senzor de lumină, soclu microSD

SLCD1 Xplained Pro – afișaj LCD cu 96 segmente

Atmel Studio 6

Admel Studio 6 este o platformă de dezvoltare integrată (IDP) gratuită pentru dezvoltarea și depanarea aplicațiilor cu microcontrolere AVR sau bazate pe Atmel ARM Cortex-M. Această platformă oferă un mediu ușor de utilizat pentru dezvoltarea și testarea aplicațiilor scrise în C/C++ sau cod de asamblare, și oferă suport pentru toate microcontrolerele AVR pe 8biți și 32 biți, dar și microcontrolerelor din familiile SAM3, SAM4 și SAM D20. Atmel Studio 6 pune la dispoziție numeroase biblioteci și exemple specifice acestor microcontrolere, prin intermediul Atmel Software Framework(ASF).

Una dintre funcționalitățile mai interesante ale Atmel Studio 6 este modul de lucru cu plăcile de dezvoltare Atmel Xplained Pro. La conectarea unei astfel de plăci prin portul USB, Atmel Studio 6 detectează tipul plăcii respective, împreună cu toate modulele de extensie atașate.

Lynxmotion 4WD1 Rover

Lynxmotion 4WD1 Rover(figura 2.3) este o platformă electro-mecanică utilizată pentru dezvoltarea de roboți teleghidați sau autonomi, având șasiul construit din aluminiu. Acest robot conține 4 motoare de curent continuu de 12V, având angrenaje reductoare de raport 30:1 și 4 roți cu diametrul anvelopelor de 4,75”.

Cele 4 roți sunt fixe, controlul direcției fiind asigurat prin diferența de turație dintre motoarele aflate pe partea stângă și motoarele aflate pe partea dreaptă a vehiculului.

Sabertooth 2x12RC

Sabertooth 2x12RC (figura 2.4)este un circuit de control al motoarelor de curent continuu. Acesta dispune de două canale și poate opera cu tensiuni de până la 24V. Totodată, prin intermediul acestei plăci se poate alimenta un circuit extern cu 5V și 1A.

Sabertooth 2x12RC dispune de 6 comutatoare prin care se poate configura modul de operare al acestuia. Acest lucru permite controlul prin conexiunea la un potențiometru(mod analogic), a unui receptor radio sau a unui microcontroler.

Una dintre funcționalitățile interesante ale acestul circuit este tehnologia regenerativă, care permite reîncărcarea acumulatorilor în momentul în care este dată o comandă de încetinire a motoarelor.

Specificațiile proiectului

Pentru dezvoltarea sistemului de teleghidare, a fost abordată o proiectare independentă a diferitelor componente, abordare motivată de principiul modularității. În figura 3.1 este ilustrată arhitectura sistemului. Astfel, telecomanda este alcătuită dintr-un dispozitiv mobile cu sistemul de operare Android pe care rulează aplicația FlexiRC. Platforma Android a fost preferată datorită disponibilității și răspândirii sale, dar și datorită flexibilității oferite în implementarea interfeței cu utilizatorul. Canalul de comunicație are la bază protocolul IEEE 802.15.1 (Bluetooth), această tehnologie fiind aleasă datorită costului redus, dar și consumului redus de energie electrică. Vehiculul telecomandat are la bază platforma electro-mecanică Lynxmotion 4WD1 Rover împreună cu controlerul de motoare Sabertooth 2x12RC. Comunicarea cu telecomanda și procesarea comenzilor se face prin intermediul platformei de dezvoltare Atmel SAM D20 Xplained Pro, bazată pe microcontrolerul SAM D20.

Fig. 3.1. Arhitectura sistemului de teleghidare

Aplicația mobile – FlexiRC

FlexiRC este o aplicație mobile concepută pentru sistemul de operare Android, care permite conectarea prin Bluetooth la un vehicul. Vehiculele comandate pot fi de două tipuri – cu direcție cu cremalieră(ex: autoturism) sau cu direcție diferențială (ex: vehicul cu șenile). Odată conectată, aplicația oferă posibilitatea operatorului de a alege unul din mai multe tipuri de interfețe, în funcție de tipul vehiculului comandat și preferința acestuia.

Denumirea are ca origine abrevierea „Flexible Remote Control” și indică flexibilitatea opțiunilor de interfațare cu utilizatorul. Figura 3.2 reprezintă sigla aplicației

Diagrama use case

În figura 3.3 este prezentată diagrama use case a aplicației FlexiRC.

Fig. 3.3 Diagrama use case a aplicației FlexiRC

Actori:

Operator – utilizatorul uman al aplicației;

Car – vehicul cu direcție cu cremalieră;

Tank – vehicul cu direcție diferențială.

Use case-uri:

Conectează prin Bluetooth – FlexiRC asigură conectarea și menținerea conexiunii între operator și vehicul;

Selectează interfață – FlexiRC oferă posibilitatea operatorului de a selecta tipul interfeței;

Comandă vehicul – FlexiRC oferă operatorului interfețe de comandă a vehiculului;

Transmite viteza și direcția – în cazul conectării cu vehicule cu cremalieră, FlexiRC transmite viteza și direcția;

Transmite viteza stânga și viteza dreapta – în cazul conectării cu vehiculele cu direcție diferențială, transmite viteza pentru motoarele din partea stângă, respectiv dreaptă.

Modul de utilizare

În figura 3.4 este afișată diagrama de interacțiuni a aplicației FlexiRC, în cazul controlului unui vehicul cu direcție diferențială.

Ecranul A reprezintă ecranul inițial al aplicației. În această fază, dispozitivul mobile este deconectat de robot. Prin atingerea butonului „Connect to vehicle” se deschide lista de selecție al modulului Bluetooth (1).

Prin atingerea oricăreia dintre elementele listei, se lansează o tentativă de conexiune. În cazul în care conexiunea eșuează(2b), se revine la ecranul A. În cazul în care conexiunea reușește(2a), se ajunge în ecranul C. Ecranul C, pe lângă afișarea mesajului „Vehicle connected” care indică faptul că dispozitivul este conectat de vehicul, permite opțiunea de selecție a unei interfețe de control. Astfel, prin atingerea butonului „Select interface” (4), se deschide lista de interfețe disponibile (D).

Atingând oricare dintre elementele listei, se deschide una dintre interfețele de control:

interfața cu butoane (ecranul E), prin atingerea „Car Buttons”/„Tank Buttons” – permite controlul discret al vitezei(10) și direcției(11) prin intermediul a 4 butoane așezate intuitiv(față, spate, stânga, dreapta);

interfața cu slider bar-uri (ecranul F), prin atingerea „Car Slide Bars”/„Tank Slide Bars” – oferă un control analogic al vitezei de deplasare(14), respectiv vitezei de rotație(15), prin intermediul celor două bări de control.

interfața cu slide bar-uri verticale(ecranul G), prin atingerea „Tank Tread Slide Bars” – disponibilă doar pentru vehiculele cu direcție diferențială, permite controlul analogic individual al vitezei șenilelor/roților aflate pe aceeași parte a vehiculului (18, 19).

Din oricare interfață se poate reveni la lista anterioară pentru a selecta o altă interfață prin atingerea butonului „Back” (13, 17, 21). Atingând butonul „Disconnect from vehicle”(5, 12, 16, 20), se realizează deconectarea dispozitivului mobile de vehicul, și se revine la ecranul A. Același efect îl are și pierderea conexiunii (de exemplu, ieșirea vehiculului din raza de acțiune).

Fig 3.4. Diagrama de interacțiuni a aplicației FlexiRC

Protocolul de comunicare

Comunicarea dintre sistemul mobile și vehicul se desfășoară prin intermediul protocolului IEEE 802.15.1 (Bluetooth). La nivelul aplicației, protocolul are la bază transmiterea unui mesaj de 4 octeți cu o perioadă de 40ms(figura 3.5). Dacă vehiculul nu primește mesaj de comandă timp de 200ms, consideră conexiunea întreruptă și oprește motoarele.

Structura mesajului de comandă diferă în funcție de tipul vehicului. Pentru vehiculele cu direcție cu cremalieră, mesajul este de tip SxDx. Primul octet este caracterul „S”(de la „speed”), al doilea octet este o valoare între -100 și 100 viteza de deplasare a vehicului (-100 înseamnă viteză maximă înapoi, 100 înseamnă viteză maximă înainte), al treilea octet este caracterul „D”(de la direction), iar al patrulea octet este o valoare între -100 și 100 și reprezintă poziția servomotorului direcției (-100 înseamnă maxim stânga, 100 înseamnă maxim dreapta).

Pentru vehiculele cu direcție diferențială, mesajul este de tip LxRx. Primul octet este caracterul „L”(de la „left”), al doilea octet este o valoare între -100 și 100 și reprezintă viteza de deplasare a motoarelor de pe partea stângă(-100 înseamnă viteză maximă înapoi, 100 înseamnă viteză maximă înainte), al treilea octet este caracterul „R”(de la „right”), iar al patrulea octet reprezintă viteza de deplasare a motoarelor de pe partea dreaptă(-100 înseamnă viteză maximă înapoi, 100 înseamnă viteză maximă înainte).

Fiecare mesajde comandă trebuie să primească un răspuns de confirmare de un octet de la vehicul. În cazul mesajelor de tip SxDx, octetul este caracterul „C”(de la „car”), iar în cazul mesajelor de tip LxDx, octetul este caracterul „T”(de la „tank”).

Dacă răspunsul nu este recepționat după o perioadă de 200ms de la ultimul mesaj transmis, aplicația consideră conexiunea întreruptă și revine la ecranul inițial.

Vehiculul

Vehiculul utilizat are la bază platforma mecanică Lynxmotion 4WD1 Rover. Acesta oferă posibilitatea controlului individual al celor 4 motoare ale sale. Pentru proiectul acesta, acestea sunt conectate 2 câte 2 la controlerul de motoare Sabertooth 2x12RC, permițând controlul diferențial al direcției vehicului. Controlerul de motoare este configurat în modul Microcontroller Independent Mode, prin intermediul celor 6 comutatoare de configurare, conform figurii 3.6. Acest mod permite conectarea piniilor de semnal S1 și S2 la un microcontroller. Fiecare dintre acești pini controlează câte două motoare (cele din stânga respectiv cele din dreapta) și sunt configurați ca pini PWM, comandați de câte un modul TC (contor/temporizator) al plăcii de dezvoltare.

Pentru stabilirea vitezei, un puls este trimis o dată la 20ms la pinul corespunzător perechii de motoare controlate. Durata pulsului controlează viteza și variază de la 1ms pentru viteză maximă înapoi, la 2ms pentru viteză maximă înainte. Pentru durata de 1,5ms motoarele sunt oprite. În figura 3.7 sunt prezentate diagramele de timp pentru cele 3 cazuri

Controlerului de motoare se face prin placa de dezvoltare Atmel SAM D20 Xplained Pro, bazat pe microcontrolerul SAM D20. Conexiunea între controlerului de motoare și placa de dezvoltare se face conform figurii 3.8.

Comunicarea cu sistemul mobile se realizează prin modulul Bluetooth RN-42, contectat la pinii USART ai plăcii de dezvoltare conform figurii 3.8.

Alimentarea întregului circuit se face utilizând o baterie formată din 9 celule Li-ion de 3,7V fiecare, totalizând o tensiune de alimentare de 11,1V și o capacitate de stocare de 6000mAh. Bornele bateriei se conectează la pinii B+, respectiv B-, ai circuitului Sabertooth 2x12RC, conform figurii 3.8.

Proiectare și implementare

Arhitectura aplicației FlexiRC

Aplicația FlexiRC este structurată pe o arhitectură MVC (model-view-controller), arhitectură recomandată pentru majoritatea aplicațiilor Android. În figura 4.1 este prezentată diagrama de clase a aplicației.

Fig. 4.1. Diagrama de clase a aplicației FlexiRC

Partea de „controller” are ca nucleu clasa FlexiApplication, clasă ce moștenește clasa Application. Clasa FlexiApplication este un „singleton” ce stochează static variabilele de stare ale aplicației și valorile momentane ale vitezelor. Pentru a evita blocarea interfeței cu utilizatorul datorită unor operațiunilor lente, conexiunea Bluetooth și comunicarea cu vehiculul sunt tratate în fire de execuție diferite.

Clasa ConnectThread, moștenitoare a clasei Thread tratează cererile de conectare la vehicul, încercând să creeze un obiect al clasei BluetoothSocket. În cazul în care conexiunea nu este realizată în 5 secunde, încercarea de conectare este oprită. În cazul în care conexiunea reușește, este creat un obiect al clasei ConnectedThread, iar obiecul clasei ConnectThread este responsabil cu menținerea conexiunii până la cererea de deconectare.

Clasa ConnectedThread, tot o moștenitoare a clasei Thread, este responsabilă cu comunicarea cu vehiculul prin gestionarea unui obiect al clasei InputStream(pentru recepție) și al unui obiect al clasei OutputStream(pentru transmisie). Pentru a transmite date, se utilizează un obiect al clasei Timer, care preia periodic (o dată la 40ms) valorile vitezelor din clasa FlexiApplication și le scrie în obiectul clasei OutputStream. Pentru a recepționa, datele sunt preluate din obiectul InputStream, când acestea sunt disponibile.

Un obiect al clasei Timer este creat în momentul în care o comandă este transmisă, pentru a cronometra timpul până la primirea răspunsului. Dacă răspunsul nu este recepționat timp de 200ms, aplicația consideră conexiunea întreruptă, obiectele claselor ConnectThread și ConnectedThread fiind distruse.

Componenta „model” este compusă din clase care moștenesc clasa Activity(activități). Activitățile sunt responsabile cu tratarea evenimentelor de interacțiune a utilizatorului cu aplicația. Clasa MainActivity este activitatea implicită a aplicației. Fiecărei activități îi corespunde un fișier XML, în care este descris layout-ul acesteia, totalitatea acestor fișiere compunând vederea(„view”).

Comportamentul dinamic al aplicației FlexiRC

Datorită faptului că operațiunile utilizatorului asupra interfeței cu acesta și comunicația cu evenimentul sunt procese asincrone, pentru asigurarea consistenței datelor, dar și comportamentului în timp real, aplicația tratează independent secvența de achiziție a comenzilor utilizatorului(figura 4.2) față de secvențele de comunicație Bluetooth(figura 4.3 și figura 4.4).

În figura 4.3, este luat exemplul interfeței cu butoane de comandă a vehiculului cu direcție diferențială. Astfel, în momentul apăsării/lăsării unui buton, evenimentul este tratat de metoda onTouch a unui obiect de clasă OnTouchListener atașat butonului. Metoda transmitTank calculează valorile atributelor valueLeftSpeed și valueRightSpeed, în funcție de valorile parametrilor speed și direction, și le stochează în obiectul aplicație FlexiApplication.

Cu o perioadă de 40ms, un obiect de clasă Timer creat în momentul stabilirii conexiunii cu vehiculul, lansează în execuție secvența de transmitere a datelor(figura 4.3). În primă fază, este stabilit tipul vehiculului prin apelul metodei getVehicleType pe obiectul FlexiApplication. În cazul vehiculelor cu direcție diferențială, din același obiect sunt preluate valorile pentru atributele codeLeftSpeed, valueLeftSpeed, codeRightSpeed și valueRightSpeed. Aceste valori

sunt introduse într-un tampon de 4 octeți și transmise la vehicul.

Fig. 4.3. Secvența de transmisie a unei comenzi

În figura 4.4 este prezentată secvența de recepție a mesajului de răspuns. La baza acesteia stă apelul ciclic al metodei read pe obiectul de clasă InputStream care încearcă să citească date recepționate. Datorită faptului că această operațiune are durată nedeterminată, și pentru asigurarea mecansimului de deconectare în cazul în care conexiunea este întreruptă, este pus la dispoziție un contor cu ajutorul căruia se limitează durata de așteptare la 200ms și se evită blocarea în ciclu infinit. Acest contor este decrementat o dată pe milisecundă. În cazul în care citirea are succes, contorul este reinițializat, datele sunt preluate, iar operațiunea este reluată. În caziul în care contorul ajunge la 0, operațiunea de citire este anulată, iar conexiunea este închisă.

Fig. 4.4. Secvența de recepție a unui răspuns

Arhitectura software a vehiculului

Sistemul software care se execută pe microcontrolerul SAM D20 și comandă vehiculul este structurat pe două nivele orizontale(figura 4.5).

Nivelul inferior, denumit nivel driver, este compus din module puse la dispoziție de biblioteca Atmel Software Framework și sunt responsabile cu comanda directă a componentelor hardware ale plăcii de dezvoltare Atmel SAM D20 Xplained.

Nivelul superior, denumit nivel aplicație, este alcătuit din modulele software responsabile cu serviciile de comunicare cu sistemul mobile și comandă a motoarelor vehiculului.

Fig. 4.5. Arhitectura software a vehiculului

Nivelul driver

Nivelul driver este formată din două module software, componente ale Atmel Software Framework. Primul modul este usart – driver-ul de comunicație serială, utilizat pentru comandarea circuitului integrat RN42-I/RM Bluetooth. A doua componentă este modulul tc – contor temporizator, utilizat pentru generarea de impulsuri modulate în lățime (PWM), necesare conducerii driver-ului de motoare Sabertooth 2x12RC. Pentru o documentație completă a acestora, se pot consulta referințele[] și [].

Funcțiile utilizate din modulul usart sunt:

Funcțiile utilizate din modulul tc sunt:

Nivelul aplicație

Nivelul superior este compus din modulele aplicației. Astfel, modulul bluetooth, este responsabil cu implementarea protocolului de comunicare cu sistemul mobile folosindu-se de serviciile oferite de modulul usart. Acest lucru constă în preluarea datelor recepționate, prelucrarea și stocarea lor.

Definițiile modulului bluetooth sunt:

Variabilele globale ale modulului bluetooth sunt:

Funcțiile exportate de modulul bluetooth sunt:

Al doilea modul al nivelului aplicație, motor, este responsabil cu preluarea datelor stocate de modulul bluetooth, prelucrarea lor și comandarea în funcție de acestea a circuitului Sabertooth 2x12RC prin intermediul serviciilor oferite de modulul tc.

Definițiile modulului motor sunt:

Variabilele globale ale modulului motor sunt:

Funcțiile exportate de modulul bluetooth sunt:

Comportamentul dinamic al software-ului vehiculului

Secvența de inițializare a software-ului vehicului

Imediat după inițializarea sistemului, prin apelul funcției system_init, are loc inițializarea modulului bluetooth, conform figurii 4.6. În primă fază se configurează modulul usart. Structura de configurație este următoarea:

config_usart->data_order = USART_DATAORDER_LSB;

config_usart->transfer_mode = USART_TRANSFER_ASYNCHRONOUSLY;

config_usart->parity = USART_PARITY_NONE;

config_usart->stopbits = USART_STOPBITS_1;

config_usart->character_size = USART_CHARACTER_SIZE_8BIT;

config_usart->baudrate = 9600;

config_usart->receiver_enable = true;

config_usart->transmitter_enable = true;

config_usart->clock_polarity_inverted = false;

config_usart->use_external_clock = false;

config_usart->ext_clock_freq = 0;

config_usart->run_in_standby = false;

config_usart->generator_source = GCLK_GENERATOR_0;

config_usart.mux_setting = EXT3_UART_SERCOM_MUX_SETTING;

config_usart.pinmux_pad0 = EXT3_UART_SERCOM_PINMUX_PAD0;

config_usart.pinmux_pad1 = EXT3_UART_SERCOM_PINMUX_PAD1;

config_usart.pinmux_pad2 = EXT3_UART_SERCOM_PINMUX_PAD2; config_usart.pinmux_pad3 = EXT3_UART_SERCOM_PINMUX_PAD3;

Cu această configurație se inițializează modulul usart, după care se activează. Următoarea fază este înregistrarea funcției bluetooth_read_callback ca funcție de callback a operațiunii de citire seriale.

În ultima fază, se inițializează variabilele bluetooth_connected, left_speed, right_speed și se resetează contorul bluetooth_timeout_counter.

Fig. 4.6. Secvența de inițializare a modulului bluetooth

După inițializarea modulului bluetooth, este apelată funcția motor_init și se lansează secvența de inițializare a modulului motor, conform figurii 4.7.

Prima fază este configurarea celor două instanțe ale structurii tc (tc_0 și tc_1). Structura de configurație este următoarea:

config->clock_source = GCLK_GENERATOR_0;

config->counter_size = TC_COUNTER_SIZE_16BIT;

config->clock_prescaler = TC_CLOCK_PRESCALER_DIV8;

config->wave_generation = TC_WAVE_GENERATION_NORMAL_PWM;

config->reload_action = TC_RELOAD_ACTION_GCLK;

config->run_in_standby = false;

config->waveform_invert_output = TC_WAVEFORM_INVERT_OUTPUT_NONE;

config->enable_capture_on_channel[0] = false;

config->enable_capture_on_channel[0] = false;

config->count_direction = TC_COUNT_DIRECTION_UP;

config->oneshot = false;

config->invert_event_input = false;

config->event_action = TC_EVENT_ACTION_OFF;

config->channel_pwm_out_enabled[0] = false;

config->channel_pwm_out_enabled[1] = false;

config->size_specific.size_16_bit.count = 0x0000;

config->size_specific.size_16_bit.

compare_capture_channel[0] = TC_20MS_PERIOD;

Cu această configurație se apelează funcția tc_init, apoi funcția tc_enable pentru amândouă instanțele, astfel încât acesea să fie inițializate și activate.

Fig. 4.7. Secvența de inițializare a modulului motor

Următoarea fază este înregistrarea și activarea funcțiilor de callback, motor_left_pwm_callback și motor_right_pwm_callback, astfel încât acestea să fie apelate periodic de modulele tc_0, respectiv tc_1.

Secvența de inițializare se încheie cu apelul funcției system_interrupt_enable_global care activează sistemul de întreruperi.

Secvența de recepție a comenzilor

Pentru recepționarea datelor (figura 4.8), funcția bluetooth_read este chemată ciclic din funcția main.

Odată recepționate datele, modulul usart apelează funcția bluetooth_read_callback. Aceasta resetează contorul de timeout. Dacă datele preluate sunt valide – tamponul conține un mesaj LxDx, în funcție de valorile primite, se calculează, aplicând pasul SPEED_STEP, valorile pentru variabilele left_speed și right_speed, conform figurii 4.9. În această formulă, v[t] reprezintă viteza recepționată la momentul t, v[t-1] reprezintă viteza recepționată la momentul t-1 și stocată la momentul t, iar p reprezintă pasul.

Fig. 4.9. Formula de amortizare a vitezei

După această prelucrare, se apelează funcția usart_write_buffer_wait pentru a transmite mesajul de răspuns, și anume caracterul ’T’. Această funcție își termină execuția abia după transmisie, și a fost preferată față de alternativa cu callback datorită simplității și timpului scurt necesar transmiterii unui singur octet.

Dacă următorul mesaj nu este recepționat mai repede de 200ms de la resetarea contorului de timeout, se va considera conexiunea întreruptă, blueetooth_connected va lua valoarea false, iar variabilele left_speed și right_speed vor lua valoarea 0.

Secvența de comandă a motoarelor

În figura 4.10 este prezentată secvența de comandă a motoarelor de pe partea stângă. Operațiunea este identică și pentru comanda motoarelor de pe partea dreaptă.

Comanda motoarelor are la bază apelul periodic al funcțiilor motor_left_pwm_callback, respectiv motor_rigth_callback, de către modulul tc(o dată la fiecare 20ms).

La fiecare apel este verificată valoarea contorului de timeout și valoarea indicatorului de conexiune, prin apelulrile bluetooth_check_timeout și bluetooth_get_connection_status. Dacă vehiculul este conectat cu sistemul mobile, se apelează bluetooth_get_left_speed, respectiv bluetooth_get_right_speed pentru actualizarea valorilor vitezelor celor două părți, și se calculează valorile duratelor impulsurilor, conform figurii 4.11.

t=1500 + 5v

Fig. 4.11. Calcularea duratei unui impuls

În această formulă, t reprezintă durata impulsului, în µs, îar v reprezintă valoarea recepționată de la dispozitivul mobile, având valori între -100 și 100.

Dacă vehiculul este deconectat, durata impulsului este 1500, însemnând că motoarele se opresc.