Author: cchima

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.

 

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.