Robot autonom pentru rezolvarea unui labirint

3 OCTOMBRIE 2014

Grație evoluției tehnologice din ce în ce mai pregnante, o serie impresionantă de activități care până odinioară erau realizate

exclusiv manual, s-au putut automatiza. Printre cele mai importante beneficii aduse de această evoluție se poate menționa creșterea gradului de siguranță pentru umanitate, deoarece omul se implică din ce în ce mai puțin în domenii cu un risc ridicat (cum ar fi mineritul). Această evoluție pare că ar pune și probleme de ordin social cum ar fi reducerea locurilor de muncă, tocmai din cauza acestui proces de automatizare. Însă, presiunea cade pe societate, care trebuie să accelereze reorientarea sistemului educațional și reconversia profesională către zone de inovație, cu valoare adăugată, lăsând tot ceea ce înseamnă mașină să opereze activitățile de rutină și/sau cele cu un efort fizic ridicat.
Cu alte cuvinte: evoluția tehnologică creează și alimentează dezvoltarea societății din ziua de astăzi.

Introducere

Articolul de față își propune să prezinte modul în care a fost construit și programat un robot destinat explorării unui labirint. Odată ce am reușit să creăm un prototip de robot capabil să exploreze un mediu și să creeze o hartă a acestuia, extinderea robotului prin adăugarea unor noi funcționalități conduc la transformarea lui, de exemplu, într-un aspirator de cameră sau de ce nu, dacă mediul este un labirint, într-un instrument capabil să determine traseul cel mai scurt dintre oricare două puncte ale labirintului. Dimensiunile acestuia permit explorarea spațiilor inaccesibile omului.
Robotul a fost echipat cu un terminal Bluetooth, astfel încât să poată transmite datele obținute de la senzorii externi către un alt terminal Bluetooth, încorporat în cadrul unui telefon mobil sau chiar al unei tablete. Datele transmise de acesta trebuie interpretate la receptor de o altă aplicație de nivel înalt, capabilă să îi ofere utilizatorului o interfață prietenoasă 3D a mediului respectiv. În cazul de față, terminalul de tip front-end este un dispozitiv mobil, peste care rulează o aplicație Android cu ajutorul căreia utilizatorul poate configura aplicația ce rulează pe placă sau poate vizualiza în timp real labirintul, structura acestuia și poziția curentă a mașinii.
Toată partea de logică se desfăşoară pe telefonul mobil, fiind efectuată de aplicația care rulează peste sistemul de operare Android. Robotul nu face altceva decât să preia periodic informații de la senzori, să le împacheteze, să le trimită prin Bluetooth, apoi să preia și să interpreteze comenzile primite de la dispozitivul partener, punându-le în aplicare. Această decizie a fost luată din raționamente extrem de simple. Ne dorim ca pe viitor să putem extinde funcționalitatea robotului cât mai ușor, fără a efectua modificări majore. Aplicarea unor algoritmi complecși precum A* ar spori nevoia de putere de calcul, generându-se astfel costuri suplimentare cu platforma hardware. Să nu uităm că dezvoltarea unor aplicații embedded trebuie să țină cont și de constrângerile platformei harware utilizate.
În cele ce urmează vor fi prezentate arhitectura și modul de funcționare al fiecărei din cele două entități, cu accent pe robotul construit și mai puțin pe dispozitivul partener.

Arhitectura robotului

Mașina a fost realizată având la bază o placă Freedom Board (FRDM-KL46Z) dezvoltată de Freescale Semiconductor peste care au fost adăugate mai multe module pentru a i se extinde funcționalitatea. La baza plăcii stă un microcontroler din seria Kinetis L și anume KL46Z. Mediul de dezvoltare folosit pentru scrierea programului de pe placă a fost CodeWarrior for MCU, limbajul C, iar pentru implementarea mai rapidă a unor drivere necesare comunicării cu modulele externe s-a utilizat un soft utilitar pus la dispoziție tot de Freescale Semiconductor, numit Processor Expert. Acest produs poate fi folosit pentru crearea, configu­rarea, optimizarea unor componente software prin care se generează automat cod sursă pentru o serie de echipamente Freescale (de la senzori până la micro­controlere). În acest fel, crearea și configurarea unui modul software care să permită comunicarea prin UART, de exemplu, devine foarte simplă, putându-se realiza direct din interfața grafică.
Avem de-a face cu o aplicație în timp real, motiv pentru care am considerat că ar fi bine să avem un sistem de operare (RTOS) între nivelul hardware și codul scris de noi. Chiar dacă acest lucru a însemnat un overhead din mai multe puncte de vedere (memorie RAM consumată, timp de execuție), marele avantaj l-a consti­tuit ușurința programării și mai ales ușurința cu care putem extinde funcționalitatea mașinii. Încă de la început, opțiunile au fost: FreeRTOS și MQX (cu varianta MQX Lite). FreeRTOS este conceput pentru sisteme mici, necesitând doar 3-4 KB de memorie flash și mai puțin de 1 KB de memorie RAM. Pe de altă parte, MQX Lite necesită aproximativ 2-4 KB de memorie RAM pentru a putea rula. În plus, diferența principală între MQX și MQX Lite o constituie faptul că ultimul nu e furnizat și cu drivere adiționale, precum drivere pentru SPI, I2C sau UART, unele dintre ele nefiind necesare proiectului. O altă diferență importantă între FreeRTOS și MQX Lite o constituie faptul că ultimul nu prezintă decât un planificator preemptiv bazat pe priorități, pe când primul prezintă și un planificator bazat pe cuantă de timp. Toate acestea au determinat ca alegerea finală să o reprezinte FreeRTOS.
În figura 1 este ilustrată o simplă diagramă bloc, parte reprezentativă pentru modulele hardware utilizate și modul lor de interconectare.

Figura 1: Ansamblul hardware

Așa cum se poate observa și din figură, dispunem de un modul Bluetooth BC-04 – folosit pentru a putea avea comunicația dintre mașină și telefon, un driver de motor bazat pe circuitul integrat L298N – ce deservește la comandarea celor două motoare de curent continuu, trei senzori de distanță cu ultrasunete HC-SR04 (poziționați astfel: unul în față, unul pe partea stangă a mașinii și unul pe partea dreaptă) – pentru detectarea obstacolelor și distanței până la ele, cât și un convertor de tensiune capabil să primească la intrare între 9 și 12V și să producă 5V, tensiune cu care se va alimenta atât Freedom Board, cât și senzorii de proximitate.
După ce avem o vedere de ansamblu, urmează să fie prezentat succint modul de conectare și configurare al fiecărui dispozitiv în parte.

1. Modulul Bluetooth

Cele două dispozitive (telefonul mobil și mașina) vor comunica wireless, prin intermediul acestei tehnologii. Standardul Bluetooth, așa cum este definit el, prevede existența a două tipuri de entități virtuale: un dispozitiv master și un dispozitiv slave. În cadrul unui pool de dispozitive conectate între ele, standardul stabilește necesitatea existenței unui singur dispozitiv master și a unuia sau a mai multor dispozitive de tip slave. Această lucrare definește dispozitivul master ca fiind robotul, iar dispozitivul slave ca fiind telefonul. Cum mai multe dispozitive slave se pot conecta și comunica în același timp cu masterul, asta înseamnă că putem utiliza mai multe telefoane pentru comandarea robotului.

Figura 2: Conectarea modulului Bluetooth la Freedom Board

Comunicația prin Bluetooth între telefonul mobil și mașină se face folosind protocolul UART (UART1), fără bit de paritate, un bit de stop și fără bit de start start, cu un baud rate setat la 9600. Inexistența unui bit de paritate și prezenţa doar a unui singur bit de stop duce la creșterea probabilității de apariție a unor erori în transmisia datelor. Acest fapt necesită crearea unui mecanism capabil să corecteze pachete primite la receptor.

2. Driverul de motor

Comandarea celor două motoare de curent continuu atașate robotului are loc prin intermediul unui driver ce are la bază un circuit integrat capabil să împartă tensiunea de intrare în mod egal sau în mod diferit către cele două ieșiri. Driverul este bazat pe circuitul integrat L298N și poate oferi la ieșire un curent maxim de 2A.

Figura 3: Conectarea driverului de motor

Pentru a varia viteza unui motor va trebui să variem tensiunea aplicată la bornele acestuia, deci putem folosi fără probleme PWM (Pulse Width Modulation). Nu voi descrie aici ce înseamnă PWM și cum funcționează, ci doar voi sublinia faptul că acuratețea controlului motoarelor de către acest driver nu este foarte bună, asta traducându-se prin imposibilitatea oferirii aceleași tensiuni de ieșire motoarelor în momentul în care se dorește aceeași viteza pe ambele roți. Această problemă va trebui cumva rezolvată software. În figura 3 este ilustrat modul în care driverul este conectat.

3. Senzorul de distanță cu ultrasunete

Ultimul element hardware deosebit de important îl constituie senzorul de distanță cu ultrasunete.
Senzorul este fără contact și funcționează pe principiul ecolocației. El poate măsura distanța până la un obstacol cu o precizie de aproximativ 3mm și, de asemenea, între următoarele limite: 2cm este limita inferioară și 4m limita superioară. De asemenea, o altă caracteristică a senzorilor HC-SR04 este unghiul de măsurare destul de mic, de doar 15°.

Figura 4: Conectarea senzorului de distanță cu ultrasunete din față

Principiul de funcționare al senzorului este destul de simplu: se emit mai multe ultrasunete – un burst de 8 la număr, după care se pornește un temporizator și se așteaptă până când acestea se întorc (ele se reflectă dacă întâlnesc un obstacol). Între timp, temporizatorul va continua să numere câte microsecunde trec până la întoarcerea lor sau până când o limită de timp este depășită. La final, acesta va stoca de fapt timpul petrecut de sunet în aer – Δt. Apoi, folosind viteza sunetului în aer, vom putea determina distanța până la un obstacol:
(1) caer = (331.3 + 0.606 × ϑ)m⁄s, unde ϑ reprezintă tempera­tura mediului în care activează mașina.
În figura 4 este ilustrat modul de interconectare al senzorului frontal la placa KL46Z. Ceilalți senzori vor fi conectați în mod asemănător, bineînțeles folosind alți pini. După ce am interconectat toate modulele hardware între ele, putem trece la prezentarea părții software și la prezentarea algoritmului utilizat în explo­rarea mediului.

Descrierea algoritmului de explorare

Faptul că mașina nu este echipată cu un servomotor conduce la îngreunarea deplasării ei mai ales în momentul în care efectuarea unor viraje este strict necesară. Acest lucru conduce la un algoritm complex necesar deplasării în linie dreaptă, efectuării unor viraje în cadrul unor intersecții sau în momentul întoarcerii. Modulele hardware atașate robotului, cât și algoritmul implementat impun, în cele din urmă, o serie de limitări ce vor fi discutate în paragrafele ce urmează.
Să presupunem că avem un labirint de lățime constantă Y, cu marginile de înălțime minimă X și intersecții pătratice de latură Y. Toate dimensiunile sunt exprimate în cm.
Inițial, robotul va fi poziționat undeva în labirint, în așa fel încât senzorii laterali să poată detecta zidurile ca și obstacole (L și R). Nu trebuie neapărat să fie poziționat exact pe axul drumului, dar trebuie ca modulul dife­renței distanțelor detectate de senzorii laterali (ΔS) să aibă o valoare mai mică decât Z. O valoare bună pentru Z ar fi 10 cm, să spunem. Acest lucru este important pentru că de fiecare dată când algoritmul detectează faptul că ΔS ≤ Z va considera că în stânga, cât și în partea dreapta a mașinii avem zid, va purcede la menținerea mașinii pe o traiectorie rectilinie. Altfel spus, atunci când mașina ar trebui să mergă în linie dreaptă, reglarea traiectoriei se va face folosind valorile obținute de la senzorii laterali. Vom rezolva problema legată de alocarea inegală de tensiune pe cele două roți.

Figura 5: Mersul în linie dreaptă

Dacă cumva ΔS > Z și distanța obținută de la senzorul din față este mai mare decât Y, se consideră că mașina a găsit ieșirea labirintului. Condiția de găsire a ieșirii labirintului mai aduce o limitare în ceea ce privește construcția lui, în sensul în care acesta din urmă nu poate conține intersecții în X, ci doar în T. În caz contrar, valorile detectate de cei trei senzori ar avea va­lori mari iar algoritmul ar considera faptul că am ajuns în starea finală, ieșirea a fost detectată. Viteza mașinii în linie dreaptă va fi direct proporțională cu distanța oferită de senzorul frontal, conducând la o îmbună­tățire a timpului de parcurgere a labirintului.
Să vedem ce se întâmplă când ne apropiem de o intersecție. În principiu, putem spune că am ajuns într-o intersecție atunci când modulul diferenței distanțelor L și R este mai mare decât Z. În acest caz, nu se mai poate face reglarea automată a traiectoriei și pentru o porțiune scurtă de drum, mașina va devia de la traiectoria paralelă cu drumul. Asta conduce la ideea că latura intersecțiilor (valorea lui Y) nu trebuie să fie foarte mare (maxim 30 de cm), pentru ca devierea să fie cât mai mică. Suntem într-o intersecție, ce facem mai departe? Răspunsul e simplu. Dacă avem opțiunea să mergem înainte atunci vom alege prima dată această opțiune, pentru că efectiv nu știm unde să ne oprim în intersecție pentru a putea efectua virajul. Apoi, vom salva poziția de pe tronsonul de unde am detectat intersecția, astfel încât în momentul virării să putem încetini și să efectuăm întoarcerea corespunzător. Astfel ne asigurăm că mași­na nu va depăși centrul intersecției. În acest caz, procesul de încetinire va începe de la distanță egală cu Y cm față de acel punct. În celălalt caz, dacă ajungem într-o intersecție în care nu avem opțiunea să mergem înainte, ne vom opri în intersecție atunci când distanța frontală va fi mai mică decât Fmin:
(2) Fmin ≤ Y – T, în acest moment mașina este complet în intersecție; (T reprezintă lungimea fizică a mașinii, adică o simplă constantă)
Acum nu ne mai rămâne decât să detectăm dacă în stânga și/sau dreapta avem drum, adică dacă avem o intersecție în formă de T sau pur și simplu o schimbare a direcției de mers. În primul caz, vom alege mereu să facem dreapta și apoi vom salva intern faptul că există o zonă nevizitată pe care o și marcăm în labirintul virtual.
Deoarece logica și comenzile pe care trebuie să le îndeplinească mașina sunt oferite de telefonul mobil, este foarte important să avem o sincronizare bună între labirintul real și construcția lui virtuală, pentru a ști cu o precizie mare unde se află mașina.

Figura 6: Dacă mașina va face mereu dreapta, ea va intra într-un ciclu infinit.

Mai mult decât atât, trebuie avute în vedere posibilele cicluri din cadrul unui labirint. Să considerăm cazul din figura 6. În acest caz, mașina își va începe mișcarea din poziția indicată și dacă va face mereu dreapta în fiecare intersecție (așa cum este sugerat și pe figură) ea va intra într-un ciclu infinit.
Rezolvarea problemei ciclului infinit presupune să ne dăm seama când ajungem într-o intersecție în care am mai fost și suntem în situația efectuării aceluiași viraj, fără să fi întâlnit o înfundătură sau fără să fim în tranzit către o zonă nevizitată.

Figura 7: Modul de virare în intersecție

Lipsa unui servomotor îngreunează foarte mult efectuarea unui viraj. Mai mult decât atât, sunt evitate întoarcerile la 180° ale mașinii pentru că acestea nu se pot face (întotdeauna) într-un singur pas, necesitând, la fel ca și în viața reală, mai multe mișcări (printre care și să mergem cu spatele). Așa încât vom efectua mereu viraje numai la 90°. În figura 7, mașina intră în intersecție și încearcă să vireze stânga. Ultrasunetele generate de senzorii de pe mașină se vor propaga conform reprezentării. Până când senzorul drepta nu va ajunge perpendicular pe peretele din față, valorile obținute de la acesta și de la senzorul frontal vor detecta distanțe mai mari decât atunci când am terminat virajul. Dacă acesta este executat la viteză mică și stând pe loc (roata din stânga se află în repaus, iar cea din dreapta înaintează) putem considera că virajul s-a terminat atunci când atingem valoarea minimă pentru fiecare din cele două raze.
În fine, ultimul caz rămas este ce comportament ar trebui să aibă mașina atunci când ajungem într-o fundătură. Nu mai putem să evităm întoarcerea, motiv pentru care vom face un artificiu și vom merge cu spatele până când ajungem într-o intersecție în care am mai fost (distanța detectată de senzorul frontal este aproximativ egală cu distanța detectată la un moment anterior de același senzor atunci când eram în respectiva încrucișare de drumuri).

Figura 8: Vedere asupra scenei 3D

Aplicația Android

Aplicația Android îi ofe­ră utilizatorului po­si­bi­litatea de a-și alege la ce dispozitiv Bluetooth par­tener să se conec­teze, ce setări ale aplica­ției să configu­reze, de a-l notifica când apar anumite excepții prin interme­diul unui sistem de jurnalizare și, cel mai important, de a-i reda în timp real forma labirintului explorat. În figura 8 este ilustrată scena 3D a labirintului. Interfața este cât se poate de simplu de utilizat și extins. După stabilirea unei conexiuni Bluetooth cu mașina, se va apăsa butonul de start și procesul de explorare va începe imediat.

Concluzii

Robotul construit poate naviga printr-un labirint simplu având la bază o serie de algoritmi pentru menține­rea traiectoriei, realizarea unor viraje, cât și găsirea ieșirii din labirint. Crearea unui labirint în care două sau mai multe intersecții sunt foarte apropiate sau a căror ziduri nu sunt perfect drepte poate conduce la o serie de probleme, cauzând imposibilitatea de a explora tot labirintul sau de a schimba direcția de mers fără a lovi obstacolele. Această limitare apare datorită faptului că nu utilizăm decât trei senzori de distantă cu ultrasunete pentru interacțiunea cu mediul extern. Un giroscop ar fi fost foarte util în stabilirea și menținerea unei traiectorii, dar acest lucru ar fi avut repercusiuni asupra costului total al proiectului.
Versiunea prezentată poate fi îmbunățită prin creșterea acurateții virajelor executate, construirea unui sistem adaptiv capabil să citească parametrii mediului în timp real și să ia decizii diferite în funcție de constrângerile detectate, încercarea de a implementa un modul prin care să permită întoarcerea mașinii (la 180°) fie de pe loc, fie în mai multe mișcări sau, de ce nu, să poată îmbunătăți calitatea sincronizării între cele două dispozi­tive ce comunică prin Bluetooth. n

Autor
Mihai Surdeanu
Software Engineer
Freescale
Semiconductor
România

Bibliografie:
www.freescale.com
www.mcuoneclipse.com

Freescale, logo-ul Freescale, Kinetis, CodeWarrior și Processor Expert sunt mărci comerciale ale Freescale Semiconductor, Inc, Reg. US Pat. & Tm. Off. Android este marcă înregistrată Google, fiind dezvoltat în prezent de OHA (Open Handset Alliance).

Freescale Semiconductor România S.R.L.

București
Tel: 021 3052 400
officero@freescale.com
www.freescale.ro

Lasă un răspuns

Adresa ta de email nu va fi publicată. Câmpurile necesare sunt marcate *

  • Folosim datele dumneavoastră cu caracter personal NUMAI pentru a răspunde comentariilor/solicitărilor dumneavoastră.
  • Pentru a primi raspunsuri adecvate solicitărilor dumneavoastră, este posibil să transferăm adresa de email și numele dumneavoastră către autorul articolului.
  • Pentru mai multe informații privind politica noastră de confidențialitate și de prelucrare a datelor cu caracter personal, accesați link-ul Politica de prelucrare a datelor (GDPR) si Cookie-uri.
  • Dacă aveți întrebări sau nelămuriri cu privire la modul în care noi prelucrăm datele dumneavoastră cu caracter personal, puteți contacta responsabilul nostru cu protecția datelor la adresa de email: gdpr@esp2000.ro
  • Abonați-vă la newsletter-ul revistei noastre