Show page

Differences

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

--- pm:prj2023:adarmaz:room-mapper [2023/05/28 16:34]
luca.seritan
+++ pm:prj2023:adarmaz:room-mapper [2023/05/29 15:57] (current)
luca.seritan
@@ Line 38: / Line 38: @@
   * 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)
   * 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>
@@ Line 43: / Line 54: @@
 </spoiler>
-Toate piesele 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.
+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>
@@ Line 56: / Line 67: @@
 ===== Software Design =====
-Pentru partea software voi folosi notiuni din mai multe laboratoare:
+Partea software a presupus doua provocari diferite:
-  * citirea senzorilor ultrasonici pe baza intreruperilor (lab 2)
+  * Localizarea robotului
-  * controlul motoarelor in PWM (lab 3)
+  * Comunicarea datelor
-  * scrierea pe cardul SD folosind SPI (lab 5)
-<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>