Month: February 2022

This week was about making decisions on our system design. Once we presented our design review, we continued to make revisions on our software. Having reduced time in the lab has been changing our schedule a lot, but we are hopeful to get working hardware with some programs flashed before we head home for spring break. Nevertheless, we worked on initializing the software-side components. We set up our github repo, provisioned our database, and started experimenting with Amazon’s python ioT & DB APIs. We also hope to translate Minu’s pseudocode into working algorithms to process collected data into “parking spot availability” information. The accuracy of this algorithm still remains our biggest concern.

I finished up drafting implementation detail slides for the design review presentation and gave the talk. After that, I ended up changing our communication stack when attempting to request cloud resource credits. We ported everything to an AWS solution i.e CloudMQTT -> AWS iOT core, MongoDB -> DynamoDB &  Atlas -> EC2. The main reason being that we felt getting credits would be more convenient under the AWS umbrella. The connection process and other components used still remain the same. I calculated our necessary resource usage for these services and our requirements can be satisfied given the free subscription limits so I did not fill out the resource request form. For example, free iOT core allows 2.5 million connection hours https://aws.amazon.com/iot-core/pricing/ (way longer than necessary for our 2 MVP spot modules)Unlikely, but if our testing is run 24/7 for prolonged days, we may later request credits to increase our DynamoDB write/read capacity units. I also walked through some mock tutorials to enable connectivity to our iOT device(See AWS console image below) and read dynamo DB’s boto3 python API to familiarize with making backend queries.

 

I did not get a chance to visit the lab this week due to the design presentations. According to our gantt chart, I was supposed to help Kanvi build the spot modules. Instead, I focused on working on pseudocode for how the back-end of our web app would look like. According to Pennsylvania law(https://www.dmv.pa.gov/Driver-Services/Driver-Licensing/Driver-Manual/Chapter-3/Everyday-Driving/Pages/Parking.aspx), the tires of the car must be within 12 inches of the curbside. We will use this metric to tune the ultrasonic sensors inside the spot modules. Since each module has its own nodemcu unit, each module will be able to communicate with the database independently. Moreover, we will be statically storing their arrangement on software via unique ids that indicate which modules are next to each other. Overall, the database will store information, such as availability, location of the spot module(coordinates), location city, unique id of module, and a “assigned user” attribute. Thus, when the web app receives a request from a user, who inputs their destination, we use geocoding (https://developers.google.com/maps/documentation/javascript/geocoding) to convert the address to coordinates, with which we can query the database. The city attribute can help index through data faster. We will use the google maps api to calculate the minimum distance (https://developers.google.com/maps/documentation/distance-matrix?csw=1). It is important that we find not one available module that is closest, but rather three modules that are next to each other, since they are spaced 8ft apart each. Furthermore, since more than one user will be requesting parking spaces, we will assign priority to requests based on the request timestamp and use a queue to process all requests. To make sure the app does not direct two users to the same parking space, we set the “assigned user” attribute for a module in the database when a spot module is technically available according to sensor information in the database but is already assigned to a user request. Everytime the module gets occupied and is no longer available, this “assigned user” attribute gets reset for future use. Next week, I hope to work with Kanvi and build the module, and work with the team overall to turn this pseudocode into code, changing details as needed.

With online presentations this week, lab time was cut short. My original plan to connect all our ordered hardware and flash a basic program onto them was not fulfilled. Instead, I was able to research and draft up a program to flash as soon as I get into the lab. I found examples of simple HTTP client/server code (http://www.nodemcu.com/index_en.html#fr_5475f7667976d8501100000f) and the firmware (https://github.com/nodemcu/nodemcu-firmware) we will have to work with in order to develop with the ESP8266 and NodeMCU platform. The NodeMCU documentation (https://nodemcu.readthedocs.io/en/release/getting-started/) helped me get started with downloading the correct flasher for my system and building an environment for programming. Now my computer should be set to program the dev board as soon as we get into the lab. I will put together the system with Minu on Monday and plan to have a debugged program flashed by the end of Wednesday!

Our team prepared for the design review this week. We focused on reviewing all the feedback from our proposal presentation last week, and examined the technical details of our system. Our main goal was to order some parts as soon as possible. Kanvi ordered the building blocks of the hardware spot modules excluding the covering. We will cover this once we have assembled the parts together. Beyond that the rest of our week focused on specificity. This included settling on the HC-SR04 sensors, the ESP8266 (hardware), MQTT, MongoDB, Python and Javascript (software). Based on feedback, we made changes to our system requirements from the operator’s perspective. We used cost, setup time as the overarching factor in determining the hardware components considering the project’s scalability as opposed to technical impressions. For example, we figured that we could build entire spot modules for as low as 15$ with Wi-fi capability so why consider LoraWaN. Our biggest risk right now is being able to obtain 95% promised accuracy in car detection based on our detection algorithm and module arrangement. If our initial algorithm doesn’t provide great results, we would have to iterate quickly in considering improved solutions with minimal overhead.

This week I researched and finalized specifications in the software workflow. I settled on storing our sensor data in aMongoDB database via an intermediary MQTT broker. Specifically, the sensor data will be sent from our hardware programming interface running the ESP8266 WiFi module to a cloud-hosted MQTT broker exposed via a Python API (https://github.com/eclipse/paho.mqtt.python). We will install Micropython on the interface for this (https://docs.micropython.org/en/latest/esp8266/tutorial/intro.html).The MQTT broker will then forward the packets to an Atlas-hosted MongoDB collection (table) via a webhook endpoint we will configure. I am currently on track for the tasks detailed on the Gantt chart. I will put in an order for “Atlas credits” once I detail the exact resource cost we need.

This week I focused on finding sensor components to prepare for the design review. I settled on the HC-SR04 ultrasonic sensor after reading an article where the sensor is interfaced with a NodeMCU (https://randomnerdtutorials.com/esp8266-nodemcu-hc-sr04-ultrasonic-arduino/). The cost of each sensor is approximately at most $2, according to amazon pack options (https://www.amazon.com/Ultrasonic-Sensors/s?k=Ultrasonic+Sensors). Additionally, the sensor requires 5V for power, so I made the decision to leave the idea of solar energy for our initial prototype and use batteries instead. Some details about the different choices of batteries are explained in this article (https://diyi0t.com/best-battery-for-esp8266/). Next, I started to research points to consider when trying to detect a parked car. If the sensors are placed along the curbside in regular intervals of about 8 ft (about half the length of an average car), then whenever there are 3 sensors in a row that are not detecting any objects, it is guaranteed that there is enough space for a car. I will continue to think about the software vs hardware tradeoffs between having a one-to-one or one-to-many relationship between the nodemcu unit and sensors. Currently, I am on track for the tasks from the gantt chart.