Author: raghavsr

This past week, I mainly focused on improving the RESQUBE software. The main issues I was trying to resolve lay in the logic behind when hosts switch between connecting to one node versus another, as well as having nodes join the mesh faster and more reliably. With regards to the first issue, I changed the logic from initially connecting to the best node, and switching every time the RSSI dropped below -75dB to now periodically checking what node the host is connected to, as well as the RSSI to all nodes, and having the best node (the node with the lowest RSSI) connect to the host. With regards to the second issue, I realized that there were some conflicts and crashes occurring at startup that was slowing down or even preventing nodes from joining the mesh, and I sorted those bugs out. Additionally, i performed some preliminary (unscientific) debugging tests with node connections to hosts and to one another to validate these changes, and on a qualitative level, it seems as though the changes worked. I still need to quantitatively test these nodes and mesh communications to check whether or not the RESQUBE mesh communications software has reached the design requirements reliably. I also need to begin implementing victim localization software changes. In regards to the schedule, I am still on schedule. No changes need to be made to the Gantt chart as of yet.

The major accomplishment I made this week was getting a first draft of the RESQUBE software halfway completed, with many of the features already completed. The specific milestones I accomplished were that I got a development environment fully set up, with the process to create the environment documented. Then, I setup the team’s GitHub repo for all of our code and project files. Next, I made a trial software using Thread for the mesh network, which worked, but didn’t include seamless integration of phone and firefighter tablet connections. I then did research, and landed upon ESP-MESH-LITE, a library that runs a mesh network over 2.4GHz WiFi, with support for custom access points and routing. I got the basic access point setup, and added features like node connection swapping, where the connected devices swap to a different node in the mesh based on signal strength (RSSI). I then performed testing with that system over 2 nodes, with connections to my laptop and my phone and dynamic IP allocation and connection switching. Then, I soldered the battery to one of the SEEED XIAO microcontrollers to test charging and battery life, which seemed to work well with adequate runtime exceeding our MVP design requirements, even during active communications and data transfers. What is left to do is fully flesh out inter-node routing, as each node acts as its own gateway, with its own subnet, and there is currently no way for packets from one subnet/node to reach another subnet/node while getting routed properly. This is required for allowing the victim to communicate with the firefighter and vice-versa over the mesh network. Given this progress, I believe I am either on or ahead of schedule, as the software development had been progressing fast.

A was written by Ishaan, B was written by Mehaan and C was written by Raghav

Risks and contingency: The main risk that we foresee is the coexistence of the thread mesh with the BLE RSSI. However, the documentation around Thread and BLE showed evidence that this was a common use case and in the scenario it is determined to not be possible, a BLE mesh is easily swappable in our system architecture.

Design Change and Schedule: This week we proposed changing the RESQUBE network from Wi-Fi mesh to Thread for a lower-power approach and conducted a trade study. The trade study was able to determine the efficacy of using a Thread based mesh with BLE scanning from the RESQUBEs for victims. This should give us a more secure mesh network that is easier to implement due to the larger pool of documentation present for Thread mesh networks and the inherent resiliency of Thread compared to BLE and WiFi. Schedule wise we are on track with our gantt chart and are ahead in regards to router and rover development.

This week, I took delivery of the 3 SEEED XIAO ESP32C6 devices that make up the core computation modules of our RESQUBES. From there, I performed a basic power-on test and USB log test to determine that these devices were not faulty on arrival. Additionally, I reviewed the documentation and specifications of these devices, focusing on the libraries used for interfacing with each of its wireless communications capabilities. From there, I performed a trade study on whether using OpenThread or BLE would be better for inter-node mesh communications. Additionally, I performed some preliminary research on the RSSI calculations, and looked at two papers on the subject, as well as their corresponding GitHub repositories. Progress is on schedule on my end, and what I hope to accomplish next week is to delve deeper into actually writing the mesh networking code using OpenThread.

Part C: … with consideration of economic factors. Economic factors are those relating to the system of production, distribution, and consumption of goods and services.

The product solution we are designing, specifically the RESQ rover and the RESQUBES, meets an economic need due to the current cost of rescue and first responder operated robots. The current state-of-the-art firefighting robots start around 20,000 dollars, and can reach into the low six figures depending on the model. In contrast, our rescue robot will come at a cost of around 1000 dollars with both the rover and three RESQUBES. This makes it far more accessible to first responders, not just in first world countries such as our own, but also in less developed countries, where modern firefighting technologies may not have been able to be adopted as of now.

Another economic factor to consider is how easy it is to obtain the required parts to build both the rover and the RESQUBES. All of the required parts are common, come off the shelf, and are all easily accessible from online distributors. This makes building another one of these robots, or another batch of RESQUBES a trivial economic endeavor, as the production and distribution of the goods required to assemble these devices are abundant.

Over the past week, the team finished doing the project proposal. Raghav Srinivasan was the presenter, and we presented on Wednesday. He was assisted in practicing by Mehaan on Tuesday, and by Ishaan on Sunday. We then met today to go over the initial bill of materials for the RESQUBES, and conducted three trade studies together for the three components: the casing, the processor, and the battery. We settled on the SEEED XIAO ESP32C6 due to its ability to communicate via WiFi, BLE, and Zigbee while maintaining low power draw, and we picked a 500 mAH battery to give it a long enough battery life even when communication stayed online for long periods. Finally we decided to go with a 3D printed case over an epoxy casting due to the signal attenuation properties of epoxy. We then placed our initial orders. Over the next week, we look to take receipt of our parts and in the meantime, look to do research on the various pros and cons of the communications interfaces available to us on our board, both for RSSI and for mesh networking. We also intend to do preliminary research on the RESQ rover.

Over the past week, we finished up the project proposal and presented it on Wednesday. I was the presenter, and I discussed the use case, scope, usage diagram, technical challenges, and labor breakdown. Then, we met on Sunday to discuss initial parts ordering for the RESQUBE. I conducted research on which SEEED XIAO model to purchase, and weighed the pros and cons of different processors, different connectivity methods, and different power consumption levels. Then I assisted in picking a battery to purchase, as well as finding links for both products on Amazon. For the next week, I look to do research on the communications protocols and mesh network software available to our chosen SEEED XIAO, and to receive our parts and build them into one RESQUBE.