Contents

Straba IOT Network Hub

See Github here

The Straba (A play on Strava) Network Hub is portal for hosting data originating from multiple Carmins (A play on Garmin, a functional reproduction of a smart watch using ESP32) . The project iterated from our previous Carmin watch by collecting data from many individual smart watches, sourcing and passing data across a wireless network/routers in a bidirectional way, making data available from any browser, and aggregating data and displaying leaders for specific metrics.

Solution Design

Main Components

We incorporated various functionalities to control a buggy with ultrasonic and LiDAR sensors for wall avoidance. Here's an overview of how the different parts of the code work together:

1. Wi-Fi Setup: The buggy connects to a Wi-Fi network using the specified SSID and password. This enables the ESP32 to communicate over the network, such as receiving commands via UDP.
2. UDP Server: It listens for incoming UDP packets on a specific port (UDP_PORT). This is used to receive commands from an external source, like a web interface or another networked device.
3. LiDAR Sensor: Configured for distance measurement, it continuously polls the LiDAR sensor to calculate distances. If the distance to an obstacle (like a wall) is less than a threshold (80 units in this case), it triggers a response (stops the buggy).
4. Ultrasonic Sensors: Both left and right ultrasonic sensors are set up to measure distances independently. They use echo callbacks to calculate the time-of-flight and, consequently, the distance.
5. Servo and Speed Control: The code controls a servo for steering and a motor for speed. It uses a PID (Proportional-Integral-Derivative) controller to maintain a target speed and adjusts the steering based on the readings from ultrasonic sensors. We used a 'left dominant'/'right dominant' system whereby the sensor that was closer to the wall would dictate the target distance the buggy was to ride alongside that wall. If the sensor that wasn't closest read a distance that was greater than a predetermined value the code would simply assign a large number to allow the dominant sensor protocol to function.
6. Alphanumeric Display: An I2C-based alphanumeric display is used, possibly for showing status information or measurements.
7. Encoder for Wheel Speed: An encoder is implemented to calculate the wheel's rotation speed, which helps in speed regulation.

Code Overview:

Upon startup, the ESP32 initializes its Wi-Fi connection and starts the UDP server to listen for commands. The LiDAR sensor continuously measures the distance in front of the buggy. If an obstacle is detected within a predefined range, the buggy stops or takes necessary action. The ultrasonic sensors on both sides assist in navigating by constantly measuring the side distances. The steer_task uses these measurements to adjust the buggy's direction. Speed is regulated based on encoder readings, and the servo motor adjusts the steering angle as per the PID controller's output. Commands received via the UDP server (start, stop, turn) control the buggy's movements, allowing remote operation. The alphanumeric display can show relevant information like speed, distance, or elapsed time.

Execution Flow:

Initialization: Wi-Fi and peripherals (like I2C, LiDAR, ultrasonic sensors) are initialized. Task Creation: Multiple FreeRTOS tasks are created for handling different components (LiDAR, ultrasonic sensors, steering, speed control, display). Operation: The buggy operates based on sensor inputs and received UDP commands. The LiDAR and ultrasonic sensors play a key role in avoiding obstacles, while the servo and motor are controlled to navigate and maintain speed.

UDP Commands and Responses:

When the UDP server receives a stop command, it activates an emergency brake (e_brake). The start command deactivates the emergency brake. The turn command initiates a 360-degree turn maneuver. This ESP32-based system showcases a sophisticated approach to robotic control, integrating various sensors and communication protocols for efficient and responsive operation.

WiFi Connection

To ensure the Carmins were connected on WiFi, we created a free DDNS account from NO-IP provider and set up local "Group 7" router to connect to the service. Then we setup our laptop as a web server (node.js server) and accessed the web server from the hosted DDNS name (on and off the BU network, e.g., from your cellular service). We made our hostname: _{group7.ddns.net} and brought up basic WiFi functionality on an ESP32 by altering the _{WIFI_SSID.}

Web Portal

Data was plotting is done through _CanvasJS which followed (1) Feeding the (live) data from the serial port directly into the browser client via socket.io as the link between the node app and the client javascript; and (2) feeding the live data to the browser while saving the data to a local file (local to the node server). The ESP32 writes sensor data to the serial port which is read by the JS file which then writes the sensor data into a _csv file (for storage purposes), which is then read and updated to the _nodeJS server. The _nodeJS server checks for after updates to the csv file and pushes it to the sensor graphs in real-time.

Time Display

For time tracking we used an alphanumeric display that interfaces with the ESP32 using I2C. The time in the present is sent to the serial port from the _nodeJS server once and is kept track of and incremented using the ESP32s own time tracking functionality.

Temperature and Buzzer

We used a thermistor to measure temperature, converted ADC values from the thermistor into Celsius values, once the Celsius values exceeded a certain set threshold (40 C) the buzzer would go off.

Activity Tracking

Activity tracking was done by a single button cycling between states. Upon first press the sampling process would start and sensor data would be processed and displayed. Upon second press the sampling would stop. Upon third press the data was reset. The cycle would continue to loop _{start->stop->reset->start->...}

Dynamic Plotting of Data

To plot our data we used similar strategy to Quest 2 with a _nodeJS server along with the _CanvasJS graphing tool to dynamically plot our data. The JS code uses _fswatch() to watch for any changes to the csv file and as soon as and since the JS writes new sensor data to the csv line by line, when the csv file updates the JS will read the data and push it to the server using socket.io. The only changes it that this time we added a new fuunctionality of the leader, for this we made a bar graph from the _CanvasJS library and pushed a variable that constantly kept track of the name and total step value of the leader.

Smart Buggy

See Github here

Our rover buggy is a robust platform for autonomous driving that makes the round trip between a spaceship and the hot springs of Venus. We implemented (1) "cruise control" (or maintaining a constant velocity under perturbations), (2) "turn-around" (reversing the direction of the vehicle), and (3) "collision avoidance" by detecting obstructions and driving around them.

The approach involved (a) attaching sensors and the ESP to your vehicle, (b) enabling control using feedback from the wheel speed sensor to maintain a speed setpoint (driving the vehicle motor), (c) using range sensors to detect and avoid objects, and (d) maintaining forward progress towards each waypoint (A and B)

Main Components

We incorporated various functionalities to control a buggy with ultrasonic and LiDAR sensors for wall avoidance. Here's an overview of how the different parts of the code work together:

1. Wi-Fi Setup: The buggy connects to a Wi-Fi network using the specified SSID and password. This enables the ESP32 to communicate over the network, such as receiving commands via UDP.
2. UDP Server: It listens for incoming UDP packets on a specific port (UDP_PORT). This is used to receive commands from an external source, like a web interface or another networked device.
3. LiDAR Sensor: Configured for distance measurement, it continuously polls the LiDAR sensor to calculate distances. If the distance to an obstacle (like a wall) is less than a threshold (80 units in this case), it triggers a response (stops the buggy).
4. Ultrasonic Sensors: Both left and right ultrasonic sensors are set up to measure distances independently. They use echo callbacks to calculate the time-of-flight and, consequently, the distance.
5. Servo and Speed Control: The code controls a servo for steering and a motor for speed. It uses a PID (Proportional-Integral-Derivative) controller to maintain a target speed and adjusts the steering based on the readings from ultrasonic sensors. We used a 'left dominant'/'right dominant' system whereby the sensor that was closer to the wall would dictate the target distance the buggy was to ride alongside that wall. If the sensor that wasn't closest read a distance that was greater than a predetermined value the code would simply assign a large number to allow the dominant sensor protocol to function.
6. Alphanumeric Display: An I2C-based alphanumeric display is used, possibly for showing status information or measurements.
7. Encoder for Wheel Speed: An encoder is implemented to calculate the wheel's rotation speed, which helps in speed regulation.

Code Overview:

Upon startup, the ESP32 initializes its Wi-Fi connection and starts the UDP server to listen for commands. The LiDAR sensor continuously measures the distance in front of the buggy. If an obstacle is detected within a predefined range, the buggy stops or takes necessary action. The ultrasonic sensors on both sides assist in navigating by constantly measuring the side distances. The steer_task uses these measurements to adjust the buggy's direction. Speed is regulated based on encoder readings, and the servo motor adjusts the steering angle as per the PID controller's output. Commands received via the UDP server (start, stop, turn) control the buggy's movements, allowing remote operation. The alphanumeric display can show relevant information like speed, distance, or elapsed time.

Execution Flow:

Initialization: Wi-Fi and peripherals (like I2C, LiDAR, ultrasonic sensors) are initialized. Task Creation: Multiple FreeRTOS tasks are created for handling different components (LiDAR, ultrasonic sensors, steering, speed control, display). Operation: The buggy operates based on sensor inputs and received UDP commands. The LiDAR and ultrasonic sensors play a key role in avoiding obstacles, while the servo and motor are controlled to navigate and maintain speed.

UDP Commands and Responses:

When the UDP server receives a stop command, it activates an emergency brake (e_brake). The start command deactivates the emergency brake. The turn command initiates a 360-degree turn maneuver. This ESP32-based system showcases a sophisticated approach to robotic control, integrating various sensors and communication protocols for efficient and responsive operation.

Wireless Interface

1. Startup Instructions: To start server, we can cd into the Website folder and run "node server.js" in console. The site interface can then seen on http://localhost:3000/. One must remember to npm install express and node-fetch and ESP32 device needs to have a UDP server listening on port 8080 to receive messages "start", "stop", "turn".
2. Destination IP Address (ESP32_SERVER_IP): The messages are sent to the IP address specified by ESP32_SERVER_IP, which in your case is set to 'group7.ddns.net'. This is the dynamic DNS (DDNS) address that should resolve to the IP address of your network where the ESP32 device is located.
3. Destination UDP Port (ESP32_UDP_PORT): The messages are sent to the port number specified by ESP32_UDP_PORT, which is 8080 in your code. This means that your ESP32 device needs to have a UDP server listening on port 8080 to receive these messages.
4. Handling in the ESP32: The ESP32 should be programmed to run a UDP server that listens on the specified port (8080). When it receives a message on this port, it should interpret and act upon the message accordingly.
5. Process Flow: When a user interacts with the buttons on the web interface served from the public directory, an HTTP POST request is sent to the /control endpoint on your Node.js server. The server then extracts the command from the request body (req.body.command). This command is converted to a string (String(req.body.command)) and sent as a UDP message to the ESP32 device at the specified DDNS address and port.

‍

Network Configuration:

For the ESP32 to receive these messages, it must be connected to a network that is accessible via the group7.ddns.net address. If the ESP32 is behind a router (which is usually the case), you'll need to set up port forwarding on your router to forward UDP traffic on port 8080 to the internal IP address of the ESP32 device.

Security Considerations:

Since your server sends commands to an ESP32 device over the internet, it's crucial to consider security implications, especially if the commands control a physical device. Make sure to secure the communication and possibly authenticate the requests to prevent unauthorized access or control.

Sketches/Diagrams

‍

IR TX,RX NFC - Secure Parking

See Github here

For this quest we implemented a parking meter system, comprised of ESP32-powered parking meters and key fobs. It integrates infrared communication, QR code functionality, and LED indicators for parking space allocation. The system communicates with an authentication server for efficient space management, which is handled through a Node.js script. Key features include Wi-Fi connectivity, peripheral integration, and task management using FreeRTOS, making the system an innovative solution for parking management.

Solution Design

Parking Meter

The parking meter has a OLED and a IR receiver that waits for a signal. Once a signal with the FobID is received the OLED is turned on the LED along with changing the LED to blue to indicate a loading state. The OLED display a generated bitmap QR code that contains the MeterID along with the FobID.

Key Fob

The key fob is an IR transmitter that sends a signal. On button press the LED indicator is changed to LOADING (BLUE) and the IR signal is sent with the FobID.

Database

The data is initialized using query.js which creates two databases one for logging the every time the database gets queryed for authentication and one for keep tracking of the unique IP addresses of the meters and fobs.

Authentication and Relaying Commands

query.js is also the code that constantly listens for requests and is the part of the system that has constant uptime. Upon initialization of the fobs and meters it pings the authentication server, if the ping is successful it sends a message that identifies the fob or meter with the device type (fob or meter) and the ID of the fob or meter. Once the server as received this message it logs the IP address it came from along with its associated IP address. Only unique IP addresses are stored in memory. Upon receiving an OK from the server recognising the device that the device is registered, the devices' ESP32 no become constant listeners awaiting instructions.

Once a query request is send through via the scanning of a QR code it sends a request to the server which broadcasts instructions only to the relevant fob and meter to change their status LEDs. For both meter and fob it sends a message TAKEN or OPEN. For the fob TAKEN means that the fob is associated with a meter and the green LED turns on. For the meter TAKEN means that the meter is taken and the RED of the meter turns on and vice versa. OPEN -> green LED for meter. OPEN -> red LED for fob.

Sketches/Diagrams

MQTT - Secure Voting Platform

See Github here

The Smart Voting is a system leverages MQTT5 technology to establish voting stations enabling users to cast their votes for their preferred Northeastern states. Options include Connecticut, Maine, New Hampshire, New York, Rhode Island, and Vermont.

The approach involved (a) attaching sensors and the ESP to your vehicle, (b) enabling control using feedback from the wheel speed sensor to maintain a speed setpoint (driving the vehicle motor), (c) using range sensors to detect and avoid objects, and (d) maintaining forward progress towards each waypoint (A and B)

Solution Design

Key Fob

Code enables the keyfob to communicate using infrared signals and UART (Universal Asynchronous Receiver-Transmitter), and also allows it to connect to a network via WiFi.

• Infrared Communication: Allows the keyfob to send and receive data via infrared signals.
• UART Communication: Facilitates wired data transmission and reception.
• WiFi Connectivity: Enables the keyfob to connect to a network for additional functionalities.
• Traffic Light Indication: Uses RGB LEDs to display different states like a traffic light system.
• Device ID Display: Features a unique way to show the device's ID using the onboard LED.
• User Interaction: Includes a button to change the device's ID.

The keyfob, once programmed with this code, operates automatically. It can send and receive data, change its display based on the received information, and communicate over a network. A user can interact with it via a button to change its ID.

MQTT ESP

This code implements a voting system using an ESP32 microcontroller. It integrates MQTT for network communication, allowing the system to publish and subscribe to topics related to voting. The application is designed to register votes from users, display voting states, and handle restrictions on voting.

• Voting and State Selection Buttons: Utilizes GPIOs for user inputs to register votes and toggle through different states.
• MQTT Communication: Leverages MQTT protocol for sending and receiving voting data over a network.
• Alphanumeric Display: Displays the current state on a 14-segment display using I2C communication.
• Restricted Voting: Maintains a list of restricted IDs, preventing them from voting.
• LED Feedback: Provides visual feedback using RGB LEDs based on voting and system status.
• Infrared Communication: Integrates IR transmission and reception for additional functionalities.

Functionality

• Vote Registration: A button allows users to submit their vote, which is then published to an MQTT topic.
• State Toggle: Another button enables users to cycle through predefined states (like Connecticut, Massachusetts, etc.).
• MQTT Operations: Connects to an MQTT broker to publish votes and subscribe to topics that restrict voting based on user IDs.
• Display State: The current state is displayed on an alphanumeric screen.
• ID Reception: Receives and processes IDs via UART, checking against a list of restricted IDs.
• LED Indicators: Changes LED colors to indicate the system status and vote validity.

MQTT JS

This Node.js application implements a real-time voting system utilizing MQTT for messaging, Express for serving web content, and Socket.io for real-time client-server communication. It monitors and updates vote counts in a CSV file and communicates with MQTT clients.

• Real-time Vote Monitoring: Listens for changes in a CSV file and updates connected clients using Socket.io.
• MQTT Integration: Connects to an MQTT broker to receive voting data and send restrictions.
• Web Server with Express: Hosts a static website and serves an HTML file for displaying voting data.
• CSV File Handling: Reads and updates a CSV file containing voting data.
• Vote Receiving via MQTT: Receives votes sent to an MQTT topic and processes them.
• Vote Count Update: Parses and increments vote counts in a CSV file based on received MQTT messages.
• Client Notification: Notifies web clients in real-time of vote updates using Socket.io.
• Web Interface: Serves a web interface where users can view the voting results.
• File Watcher: Monitors changes in the CSV file to trigger client updates.

HTML Votemap

VoteMap is a web application designed for live visualization of polling data across different states. It uses D3.js for rendering an interactive map, Socket.io for real-time updates, and a backend that monitors vote counts in a CSV file. This application provides a dynamic, user-friendly interface to display and interact with live polling data.

• Interactive Map Visualization: Utilizes D3.js to render an interactive map of the United States, displaying voting data per state.
• Real-time Data Updates: Socket.io integration enables real-time updates to the map as new votes are recorded. CSV File Monitoring: Back-end logic watches for changes in a CSV file containing vote counts, triggering updates to the front end.
• Responsive Design: Adapts to different screen sizes for optimal viewing on various devices.
• Map Rendering: Upon loading, the application renders a map using GeoJSON data and colors each state based on the number of votes.
• Data Processing: Reads voting data from a CSV file and maps it to the corresponding states on the map.
• Real-time Interaction: Listens for 'file-updated' events via Socket.io to refresh the map and leaderboard with the latest data.
• Leaderboard Display: Shows the top three states with the highest vote counts in a dynamically updated leaderboard.

Sketches/Diagrams