Show page

Differences

This shows you the differences between two versions of the page.

--- pm:prj2023:adarmaz:room-mapper [2023/05/03 14:27]
luca.seritan Add list of used parts
+++ pm:prj2023:adarmaz:room-mapper [2023/05/29 15:57] (current)
luca.seritan
@@ Line 7: / Line 7: @@
 ===== Descriere generală =====
-Robotul va avea functionalitatea de a explora o incapere si a mapa obstacolele din ea.
+Robotul are capacitatea de a fi controlat si a transmite in timp real pozitia sa si pozitia obstacolelor pe care le detecteaza pe o retea WiFi.
-Pentru a realiza acest lucru, va utiliza:
+Localizarea este realizata cu ajutorul encoderelor de pe micromotoare, iar detectarea obstacolelor este facuta de trei senzori ultrasonici.
-  - motoare de tip stepper pentru deplasare si localizare simultana
+Microcontroller-ul ce are la baza chip-ul ESP-WROOM-32 se ocupa pe de o parte de controlul si calculele de pe robot, cat si de comunicarea wireless, dubland ca un AP la retea.
-  - mai multi senzori ultrasonici pentru detectarea obstacolelor in mai multe directii
-  - un card SD pe care harta va fi stocata la finalul explorarii
-Pentru stocare, voi testa doua variante pentru a verifica care este mai ok:
-  * stocarea hartii intr-un format ascii, asemenea unei matrice (cred ca va fi mai precis, dar va ocupa multa memorie de care arduino nu dispune)
-  * stocarea hartii sub forma unor puncte / linii de obstacole in baza carora sa pot genera mai apoi intreaga harta (cred ca voi putea mapa o zona mai mare, dar va fi nevoie de postprocesare)
 ===== Schema Bloc =====
-{{https://ocw.cs.pub.ro/courses/_media/pm/prj2023/adarmaz/room-mapper-schema-bloc.png}}
+{{ https://ocw.cs.pub.ro/courses/_media/pm/prj2023/adarmaz/mapping-robot-schema_bloc_final.png |Schema bloc }}
-<note tip>
-O schemă bloc cu toate modulele proiectului vostru, atât software cât şi hardware însoţită de o descriere a acestora precum şi a modului în care interacţionează.
-Exemplu de schemă bloc: http://www.robs-projects.com/mp3proj/newplayer.html
-</note>
 ===== Hardware Design =====
 Piese utilizate:
-  * Placa compatibila Arduino UNO
+  * Placa dezvoltare D1 R32, ESPDuino-32, ESP32, WiFi si Bluetooth
-  * Motor pas cu pas 28BYJ-48
+  * Micro Motor cu Reductor și Codor Pololu
-  * Driver motor pas cu pas ULN2003
+  * Modul driver motor, punte H duala, DRV8833
   * Senzor ultrasonic de distanta HC-SR04+
   * Sursa stabilizatoare de tensiune LM2596
-  * Acumulatori
+  * Modul Convertor nivel logic I2C bidirectional 8 Biti TXS0108E
+  * Placa prototipare
+  * Baterii AA litiu
+  * Baterie portabila
+  * Roti
+  * Ball casters
+  * Piese printate
-<note tip>
+Design-ul robotului a fost realizat integral in Fusion360, iar modelul final este open source, disponibil [[https://myhub.autodesk360.com/ue2c32f27/g/shares/SH512d4QTec90decfa6ea17dfd6e8e0d9e44|aici]].
-Aici puneţi tot ce ţine de hardware design:
-  * listă de piese
+Am urmarit cateva principii de-a lungul realizarii sale:
-  * scheme electrice (se pot lua şi de pe Internet şi din datasheet-uri, e.g. http://www.captain.at/electronic-atmega16-mmc-schematic.png)
+  * Sa aiba dimensiuni reduse pentru a putea accesa cat mai multe locuri
-  * diagrame de semnal
+  * Sa aiba centrul de greutate cat mai jos, pentru stabilitate (de aceea bateriile sunt dedesubt)
-  * rezultatele simulării
+  * Sa aiba rotile pe centru. Avand doar doua motoare, acest lucru ajuta atat la un control mai bun, cat si o localizare mai simpla (ar fi devenit mai complicat daca avea doar tractiune fata/spate si mai greu de condus)
-</note>
+  * Sa fie usor, pentru a nu solicita motoarele si a putea folosi roti cat mai mari - acest lucru ajuta pe de o parte la deplasarea pe un teren denivelat, iar pe de alta parte la o viteza mai mare a robotului.
+<spoiler Etape proiectare 3D>
+^  Etapa  ^  Screenshot Fusion360  ^
+|  Forma intiala sasiu  |  {{:pm:prj2023:adarmaz:mapping-robot-sasiu.png?400|}}  |
+|  Amplasare aproximativa componente  |  {{:pm:prj2023:adarmaz:mapping-robot-aliniere.png?400|}} |
+|  Crearea suportilor  | {{:pm:prj2023:adarmaz:mapping-robot-suporti.png? 400|}} |
+|  Adaugare placuta senzori si baterie  | {{:pm:prj2023:adarmaz:mapping-robot-senzori-baterie.png?400|}} |
+|  Adaugare componente electrice si cosmetizare | {{:pm:prj2023:adarmaz:mapping-robot-proiectare-finala.png?400|}} |
+</spoiler>
+<spoiler Randari cu modelul final>
+{{mapping-robot-randare-stanga.png?250|Randare stanga}}{{mapping-robot-randare-centru.png?250|Randare centru}}{{mapping-robot-randare-dreapta.png?250|Randare dreapta }}
+</spoiler>
+Toate componentele electronice sunt fie montate pe sasiu cu cate un suport special, fie sunt montate pe o placuta de prototipare care este apoi prinsa de sasiu. Am optat pentru lipirea unor headeri de pini pe placutele de prototipare, in locul lipirii direct a pieselor pentru inlocuirea usoara a acestora in caz de defect. De asemenea, nu riscam sa defectez piesele in timp ce lucram la lipituri.
+<spoiler Lipituri>
+{{mapping-robot-center-board-picture.jpeg?250|Placa prototipare centru}}{{mapping-robot-front-board-picture.jpeg?250|Placa prototipare senzori}}{{mapping-robot-headers-picture.jpeg?250|Headeri pini}}
+<note important>Daca le numaram cu grija, observam ca din placuta din poza centrala, cea care corespunde celor trei senzori ultrasonici ies doar 6 fire (pentru 12 pini). Acest lucru se datoreaza pe de o parte faptului ca GND si 3.3V sunt comune celor trei senzori, iar mai putin evident este faptul ca putem lega in paralel si cei trei pini de pulse ai senzorilor. Acest lucru face economie de **doua fire si doi pini** si pastreaza functionalitatea. (Cand vrem sa citim un senzor, putem trimite o unda din toti senzorii de-o data si sa citim impulsul de echo doar de pe cel care ne intereseaza, iar senzorii nu vor interfera intre ei datorita pozitionarii perpendiculare)</note>
+{{ mapping-robot-aint-much-meme.jpeg?500 |2 fire si 2 pini}}
+</spoiler>
 ===== Software Design =====
+Partea software a presupus doua provocari diferite:
+  * Localizarea robotului
+  * Comunicarea datelor
-<note tip>
+==== Localizare ====
-Descrierea codului aplicaţiei (firmware):
-  * mediu de dezvoltare (if any) (e.g. AVR Studio, CodeVisionAVR)
+Unicul mecanism utilizat pentru localizarea robotului sunt encoderele de pe motoare.
-  * librării şi surse 3rd-party (e.g. Procyon AVRlib)
+Valorile encoderelor sunt calculate utilizand intreruperi, iar la fiecare trecere prin bucla este calculata o estimare a deplasarii robotului din momentul ultimului update. Nu putem fi siguri ce traseu a urmat robotul intre doua treceri prin bucla, dar putem //presupune// cum s-a deplasat, iar la o frecventa suficient de mare a acestor update-uri putem avea o localizare //good enough//. Totusi, aceasta metoda acumuleaza erori la fiecare calcul si nu este o metoda fiabila pentru mult timp. Acest lucru ar putea fi imbunatatit prin adaugarea si a altor metode de localizare.
-  * algoritmi şi structuri pe care plănuiţi să le implementaţi
-  * (etapa 3) surse şi funcţii implementate
+La fiecare trecere prin bucla, putem vedea cat de mult s-au modificat valorile celor doua encodere:
-</note>
+$$\Delta encoder = encoder\_count - previous\_encoder\_count$$.
+Putem calcula cat de mult s-a deplasat o roata a robotului, stiind cate tick-uri are un encoder per rotatie:
+$$d = \frac{\Delta encoder}{ticks\_per\_rotation} * 2 \pi radius_{wheel}$$
+Putem calcula si cat de mult s-a rotit robotul, gandindu-ne ca s-a deplasat de-a lungul cercului pe care se situeaza cele doua roti:
+$$\Delta \Theta = \frac{\Delta encoder_{left} - \Delta encoder_{right}}{\pi * distance_{wheels}}$$
+Pentru a actualiza pozitia curenta, vom presupune ca robotul s-a deplasat pe o distanta $d_{m} = \frac{d_{left} + d_{right}}{2}$ la un unghi $\Theta_{m}=\Theta + \frac{\Delta \Theta}{2}$, actualizand in final coordonatele:
+$$x_{t+1} = x_{t} + d_{m}cos(\Theta_{m})$$
+$$y_{t+1} = y_{t} + d_{m}sin(\Theta_{m})$$
+$$\Theta_{t+1} = \Theta_{t} + \Delta \Theta$$
+==== Comunicarea ====
+Initial ma gandeam ca robotul sa salveze harta pe un card SD si sa poata fi apoi vizionata. Apoi m-am gandit ca e foarte neinteresant si ca ar fi mult mai smecher sa o transmita in timp real pe laptop pentru vizionare. Aceasta idee a atras dupa sine si o provocare: programul meu ar deveni IO bound, ceea ce ar distruge **complet** ideea de localizare mai sus mentionata.
+Din fericire, placuta bazata pe chip-ul ESP-WROOM-32 are capacitati integrate de WiFi, asa ca am ales acest mediu pentru transmitere.
+La pornirea codului, robotul creeaza o retea WiFi pentru care este si AP. Apoi asteapta conectarea unui alt dispozitiv la aceasta retea.
+Partea de comunicare este compusa din:
+  * robot
+  * un client sub forma unui script python, care ruleaza pe un alt dispozitiv
+La fiecare trecere prin bucla robotul:
+  * verifica daca a primit vreun pachet de comanda si actualizeaza vitezele motoarelor
+  * transmite catre laptop un pachet cu datele curente: pozitie si distanta pana la obstacole
+Clientul:
+  * ia input de la un joystick si trimite un pachet catre robot cu vitezele pe care sa le dea motoarelor
+  * asculta pentru pachete de la robot si realizeaza in timp real harta pe baza datelor primite
+Pentru comunicare am ales sa folosesc protocolul UDP. Am facut aceasta alegere din mai multe motive:
+  * am vrut o comunicare simpla, direct cu socketi, fara biblioteci complexe care sa adauge un overhead
+  * eram familiarizat cu acest protocol
+  * este o aplicatie cu viteza foarte mare, cu multe update-uri si multe pachete. Daca se pierd cateva din cand in cand, nu e //mare chestie//
+  * nu am vrut un protocol cu gestiunea vitezei de transmitere (precum TCP) deoarece este o aplicatie real time wireless, pe o conexiune care nu stiam de la bun inceput cat de reliable e, iar ultimul lucru pe care mi-l doream ar fi fost ca protocolul sa incetineasca si mai mult comunicarea
+==== Organizarea sarcinilor ====
+Asa cum am mentionat, trebuie ca robotul sa indeplineasca doua task-uri cu sarcini complet diferite:
+  * localizarea care este CPU bound si are nevoie de o frecventa cat mai mare
+  * comunicarea care este IO bound si care incetineste cu mult viteza codului
+<note important>Din fericire, acest microcontroller este **dual core**.</note>
+Din acest motiv, am impartit rularea codului pe cele doua core-uri in cel mai firesc mod posibil:
+  * un core se ocupa strict de calculele de localizare
+  * un core se ocupa strict de comunicare
 ===== Rezultate Obţinute =====
-<note tip>
+Robotul este functional (cel putin ca proof of concept).
-Care au fost rezultatele obţinute în urma realizării proiectului vostru.
-</note>
+{{ mapping-robot-final-picture.jpeg?500 | Roomba final}}
+<html>
+  <iframe
+    src="https://www.youtube.com/embed/DAt0vxb_2s0"
+    title="YouTube video player"
+    frameborder="0"
+    allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share"
+    allowfullscreen
+    style="aspect-ratio: 16/9; width: 100%;"
+  ></iframe>
+</html>
+<html>
+  <iframe
+    src="https://www.youtube.com/embed/644kY7WfhFs"
+    title="YouTube video player"
+    frameborder="0"
+    allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share"
+    allowfullscreen
+    style="aspect-ratio: 16/9; width: 100%;"
+  ></iframe>
+</html>
 ===== Concluzii =====
+Sunt foarte multumit de rezultat, am avut multe provocari si cred ca am reusit sa aduc robotul intr-o forma buna.
+Am invatat multe lucruri de-a lungul acestui proiect si m-am distrat realizandu-l. Totodata, deja am multe idei pentru imbunatatiri ale unor versiuni viitoare:
+  * Trecerea la un sasiu cu 4 motoare, pentru a putea trece mai usor peste denivelari
+  * Utlizarea unor metode mai bune de localizare: adaugarea unui giroscop, utilizarea unei camere video
+  * Utilizarea unor metode mai bune de detectie a obstacolelor: senzor LIDAR, camera video
+  * Schimbarea metodei de comunicare pentru a fi mai fiabila
+  * Protejarea canalului de comunicare. Metoda curenta functioneaza, insa sunt sigur ca microcontroller-ul poate fi atacat foarte usor cu un DOS.
 ===== Download =====
-<note warning>
+<note important>Codul este disponibil pentru download pe [[https://github.com/LucaSeri/roomba|github]]. </note>
-O arhivă (sau mai multe dacă este cazul) cu fişierele obţinute în urma realizării proiectului: surse, scheme, etc. Un fişier README, un ChangeLog, un script de compilare şi copiere automată pe uC crează întotdeauna o impresie bună ;-).
-Fişierele se încarcă pe wiki folosind facilitatea **Add Images or other files**. Namespace-ul în care se încarcă fişierele este de tipul **:pm:prj20??:c?** sau **:pm:prj20??:c?:nume_student** (dacă este cazul). **Exemplu:** Dumitru Alin, 331CC -> **:pm:prj2009:cc:dumitru_alin**.
+===== Bibliografie/Resurse =====
-</note>
-===== Jurnal =====
+[[https://drive.google.com/file/d/1JTzyLH7v0MgjwvOnUrzih87RpIXkxrZg/view|Datasheet ESP32]]
-<note tip>
+[[https://randomnerdtutorials.com/esp32-dual-core-arduino-ide/|Multithreading pe ESP32]]
-Puteți avea și o secțiune de jurnal în care să poată urmări asistentul de proiect progresul proiectului.
-</note>
+[[https://howtomechatronics.com/tutorials/arduino/ultrasonic-sensor-hc-sr04/|Tutorial HC-SR04]]
+[[https://randomnerdtutorials.com/esp32-useful-wi-fi-functions-arduino/|Tutorial WiFi ESP32]]
-===== Bibliografie/Resurse =====
-<note>
-Listă cu documente, datasheet-uri, resurse Internet folosite, eventual grupate pe **Resurse Software** şi **Resurse Hardware**.
-</note>
 <html><a class="media mediafile mf_pdf" href="?do=export_pdf">Export to PDF</a></html>