Team A4: RESQ

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.

This week focus was on figuring out specific metrics and testing scenarios for the rover and RESQUBES. This involved finalizing our BOM for the rover and then determining individual parts’ performance and validity for our system. In addition to this, I explored available software resources, particularly in SLAM, locomotion, and mesh networking, for the rover and nodes. With this our team was able to determine the requirements for integration and implementation of the software systems. The resources we found as a team have shown that the implementation of our system looks to be realistic in our timeframe without need for scaling back.
In addition to this, I put requests and orders for more hardware components we needed. Importantly I chose hardware such that it would be realistic to swap out in the rover without need for significant change in software and no change in scope. 

Part A: In considerations of public health, safety, and welfare, the most important aspect of our project is the victim and their safety. RESQ is intended to ensure the safety and well being of potential victims in a hazardous scenario while minimizing risks of rescue workers. The rover’s ability to map out rescue areas and identify hazards, listen to signals from victims’ phones, and relay information back to first responders all contribute to support survivors’ physical safety and well-being by helping teams identify where to focus their efforts.
The system must importantly avoid creating false confidence. Distortions in RF signals due to debris and unforeseen hazards could both compromise the information being given to first responders. Because of this, it is important to be transparent with the information being given to first responders and ensuring they have a full understanding of the information our rover provides. Importantly, we want to aid and support in rescue operations not fully replace their search methods and eliminate human oversight into rescue operations. 

This past week I worked on trade studies for our BOM. Specifically for our LIDAR and chassis. I evaluated the LIDAR on metrics such as cost, sampling rate, range, and compatibility, while I evaluated the chassis on metrics such as cost, speed, layout, compatibility and weight constraints. I also researched different SLAM libraries and compatibility with our hardware.

Additionally, I worked on preparing the design presentation slides. I worked on the contents for the use case and success criteria and the technical risks and mitigation slides, and structuring the rest of the slides. Since I am presenting this time around, I will also be working on the presentation for the rest of the weekend.

In the coming week, I hope to finalise all the libraries that we will be using and start working on path planning.

Please write a paragraph or two describing how the product solution you are designing will meet a specified need with consideration of social factors. Social factors relate to extended social groups having distinctive cultural, social, political, and/or economic organizations. They have importance to how people relate to each other and organize around social interests.

RESQ is designed to help emergency responders share information when regular communications are unavailable during search and rescue ops. This matters a lot when we are looking at crowded buildings where residents might be hard to reach and account for. The cooperating phone, however, should only be used as a signal, since some victims might have a dead battery. Therefore, responders can treat the signal as a clue, and still go in after preliminary scans to search for more victims.

This past week we completed the proposal presentation. I specifically contributed building up and quantifying the use case requirements as well as the scope. I also helped Raghav practice presenting on Tuesday (9/15). Apart from that, we started working on the design for the RESQUBE. I assisted in conducting trade studies for the processor and batteries – dimensions and run time. During our weekly meeting, I ended up placing the order for the XIAO ESP32C6, after concurrence on communication capabilities. I am currently on schedule. Over the next week, I will help in formalising the design presentation, as well as look to finalise the RESQ BOM. This would include researching and identifying the chassis, sensors, and other motor control components.

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.

This week I helped in making and preparing Raghav for the presentation on Monday and met with the team for our weekly meeting to discuss the plan forward.

For the weekly meeting, we touched on RESQube construction and part selection. I helped conduct a trade study for the microcontroller, battery, and epoxy being used for the RESQubes, selecting primarily for low-cost and small footprints. In addition, we discussed possible testing for the RESQubes to be done after construction and landed on testing propagation efficiency and power testing.

At the end of the meeting we had completed our BOM for the RESQubes, made a preliminary BOM for the RESQ rover, and put in orders for the construction of the first RESQube.

Future plans include receivin the parts, constructing the first RESQube, and testing the possible communication interfaces and bandwidths available for the mesh network and RSSI solution. 

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.