Show page

Differences

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

--- pm:prj2026:jan.vaduva:raul_ionut.nastasie [2026/05/16 23:09]
raul_ionut.nastasie
+++ pm:prj2026:jan.vaduva:raul_ionut.nastasie [2026/05/24 17:36] (current)
raul_ionut.nastasie
@@ Line 42: / Line 42: @@
 Even after control of the sensor, servos and motors was moved to the newly added ESP8266, the issue persists, as the microcontrollers doesn't have neither internally implemented Bluetooth, nor enough pins to attach a Bluetooth module. While an ESP32 (with integrated Bluetooth) might've been preferable in this situation, time and budget constraints did not allow purchasing of another microcontroller.
+Another worth-mentioning design choice: the 9 V battery originally intended as the MB102's input ended up being swapped for a second 6×AA pack. A regular 9V battery simply couldn't source the peak current the ESP32-CAM draws while streaming, as well as the servos + ultrasonic sensor. The 6×AA stack supplies the same ~9 V nominal but with much more current headroom, and the live feed has been stable since.
 ==== Hardware Modules ====
+| |
 | Adafruit Feather HUZZAH ESP8266 |
 | ESP32-CAM (AI-Thinker) |
@@ Line 64: / Line 67: @@
 ESP8266 (Feather HUZZAH):
+| |
 | GPIO 4  | Servo 1 — signal |
 | GPIO 5  | Servo 2 — signal |
@@ Line 82: / Line 86: @@
 | (all other pins) | Not connected |
+==== Labs used ====
+  * **GPIO** — driving the servo signal pins, the L298N direction inputs, and the bidirectional ultrasonic SIG line.
+  * **PWM** — generating the speed-control duty cycles for the L298N's ENA and ENB inputs that set how fast each DC motor turns.
+  * **USART** — the Serial Monitor output over USB used for general debugging, plus the boot-time Wi-Fi connection status prints, which is how we know the ESP8266 actually came up and what IP it grabbed.
+  * **I2C** (SCCB variant) — runs internally on the ESP32-CAM module between the Ai-Thinker chip and the OV2640 image sensor. We don't touch this bus ourselves — the stock camera firmware drives it — but it's the protocol that gets the picture out of the sensor and into the framebuffer that gets MJPEG-encoded.
 ===== Software Design =====
-TBA
+The host runs a Python script that reads the DualShock 4 via pygame/SDL2, parses the inputs (including clamping of values from left thumbstick), maps the right stick to two servo angles, and POSTs the snapshot as JSON to the ESP8266 at 20 Hz over the LAN. The Triangle button hits a separate /mode/toggle endpoint. Identical snapshots aren't re-sent — the host only POSTs when something actually changes, so the rover's tiny HTTP stack isn't drowning in duplicates while the operator's hands sit still.
+The ESP8266 sketch is a small Arduino program that runs an HTTP server with two endpoints (/control, /mode/toggle). In **manual mode** it just unpacks the JSON into direction-and-duty signals for the L298N plus a couple of Servo.write() calls, with a 1-second host-silence failsafe that kills the motors if the PC stops talking. In **autonomous mode** it ignores the incoming /control packets entirely and runs a small state machine: ping the ultrasonic every 60 ms, drive forward at full PWM while clear, pivot left briefly when an obstacle is detected closer than 6 cm, re-sample, if still blocked pivot right twice as long, repeat until something opens up. Readings closer than 3 cm are dropped as sensor ringdown — they were the main culprit for the rover thinking it had hit a wall when it hadn't.
+The ESP32-CAM, meanwhile, runs the stock **CameraWebServer** example from the Arduino-ESP32 distribution, unchanged: it joins the same Wi-Fi network and serves an MJPEG stream on port 80. The host pulls that stream over HTTP and shows it in its own window. The control plane (PC ↔ ESP8266) and the video plane (PC ← ESP32-CAM) are entirely independent — neither side knows about the other, which means a hiccup on the video side can't stall the controls, and vice versa.