Team A4: RESQ

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.

Risks & Contingency:

Design Changes and Schedule:
This week the team focused on completing the design report while simultaneously working on the Rover and RESQUBE subsystems. On the rover side, the exploration system implementation began using ROS2, Nav2 and a custom exploration layer. On the RESQUBE side, development and testing with the ESP32 continued. The enclosure for the RESQUBE has also been designed and pushed to printing, with alternatives depending on RSSI benchmarking and validation made. Alternatives currently include configurations using the onboard antenna, external patch antenna, external rod antenna, and a RF power amplifier for external antenna.
No major system level changes. The team remains on schedule.

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

Part A – Global Factors:
RESQ is designed for emergency response environments that vary across regions. Disaster sites may have different building layouts, construction materials, communication infra and responder resources. The system we are building is agnostic to all of these factors. While we are not testing across different disaster locations, we will be testing in various unfamiliar indoor environments.

Another global factor that we considered is that responders might have different technical expertise when it comes to operating specialised equipment. Our system addresses this by being autonomous when it comes to rover navigation and node deployment for the mesh network. All that the responders would need to do is deploy the rover, and have a device to view all the information.

Part B – Cultural Factors:

The main relevant cultural factors held in common by many nations is that they have a dedicated system for ensuring the preservation of their citizens lives. They do that through the establishment, legally, behaviorally, and morally, of various first responder branches, such as firemen, paramedics, and policemen. RESQ serves the moral aspect of saving lives, as countries value the lives of not only their citizens, but those of their first responders, and our creation aims to reduce the time spent by both victims and first responders in harms way. RESQ serves the legal cultural aspect of saving lives by having our system work with legally established organizations within a government. Finally, our system works with the behavioral aspect of cultural factors by leveraging the widespread use of smartphones, laptops, and other internet enabled devices, as well as their proximity to people, to help with the localization of victims in emergency situations.

Part C – Social Factors:

One of the primary social factors considered in RESQ is improving public safety by reducing the risks faced by first responders. In disaster scenarios, locating victims can be dangerous and time-consuming. RESQ addresses this by autonomously exploring hazardous environments and identifying potential victim locations before responders enter, reducing their exposure to dangerous conditions.

Another social consideration is the accessibility of emergency response technology. Many smaller communities lack the resources for expensive robotic systems. RESQ aims to address this by using low-cost, commercially available components, making search-and-rescue technology more affordable. Additionally, leveraging victims’ existing smartphones reduces the need for specialized equipment.

 

Work Completed this Week:
This week, I moved from architecture planning to building out the navigation software. I implemented the initial frontier based exploration algorithm that uses an occupancy grid to identify unexplored regions and select exploration targets for the rover. I also began building the ROS interface for the exploration layer. Initial navigation has been merged to the team’s repo.

I also spent time working on the design review report, working on the use case requirements and design requirements sections.

Schedule Status:
I’m on schedule. I was supposed to start on implementation, which has been done. Full rover integration is will only begin at the end of this month.

Deliverables for next week:
Testing the exploration software with ROS2 and connect it to a simulated navigation pipeline. I will also begin debugging the interaction between the SLAM generated maps, our exploration logic, and Nav2.

This week I focused on finalising the core libraries that works well with our defined hardware. I decided to use ROS2 with Nav2 and SLAM Toolbox as the core navigation infrastructure. Nav2 provides the planning, and obstacle-avoidance infrastructure, while SLAM Toolbox provides mapping/localization and integrates directly with Nav2.

Rather than implementing the entire navigation stack ourselves, our plan is to configure these libraries for RESQ and implement our own BFS exploration layer. This layer will use the generated occupancy map to identify unexplored  areas, select the rover’s next exploration target, and send that target to Nav2 for safe path planning and execution. I also began defining how LiDAR data, encoder odometry, SLAM, exploration, and motor commands will interact through ROS.

Schedule status: I am currently on schedule. Since the physical chassis is not expected to arrive until after fall break, the navigation system will initially be developed and tested in simulation. Most of the high level navigation software should be developed before integration with physical sensors and the chassis.

Deliverables for upcoming week: Establish initial ROS2 navigation development environment and get a simulated rover navigating a simple indoor environment. This will use simulated LIDAR and odometry data feeding into SLAM toolbox, generate an occupancy map, and use Nav2 to command the simulated rover.

 

This week I focused on the development of the RESQ rover and RESQubes. My primary focus was on CAD for RESQube structure, RSSI and RF feasibility studies, component selection, and compatibility testing for the RESQ rover.

For the RESQube construction, I began working on a CAD of the external housing with respect to the dimensions of the RESQube’s components and I conducted some test prints using TPU and PLA to tune the settings of one of the 3D printers we are using and that I own.

For RSSI and RF feasibility studies, I assisted Raghav in his analysis of the mesh network’s feasibility for Thread, ESP-Mesh-Lite, and BLE. From the results he found, I determined along with Raghav and Mehaan that we would require a separate patch or rod antenna for each RESQube and to utilize ESP-Mesh-Lite. This was because the attenuation on the on board antennas was far too weak for our use cases, meaning both the RSSI and node-node mesh would be deficient for our purposes. As such, I conducted a trade study between two patch antenna and one rod antenna compatible with the ESP32-C6 and found a suitable patch antenna that satisfied our SWaP-C needs. Lastly, I worked on compatibility testing between the  Jetson Orin Nano, eYs 3D camera, and Intel RealSense LiDAR camera L515. This preliminary testing showed good compatibility between all 3 and showed that our high level system architecture is feasible.

For the weekly meeting, we covered the feasibility study and ordered new antennas, the rover chassis, and discussed our design report. For the design report we are transferring our work and testing results into it to help build the structure better.

For the week ahead we are aiming to finish the system implementation of the RESQubes and testing, which seems feasible with the antennas we ordered coming on Monday. In addition, I hope to finish my parts of the design report that were divided up to me and get a head start on more of the rover’s system architecture, specifically on victim localization using the three prototype RESQubes we will have.

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.

Design Change and Schedule: For design changes, our team tested out some of the options for mesh, namely Thread, BLE, and ESP-Mesh-Lite. In our study, we saw a lot more success in the implementation of ESP-Mesh-Lite.This was primarily because the system itself showed better promise for our use case over Thread and BLE alone. We also opted for a discrete additional antenna for our RESQubes since the onboard antenna showed disappointing results in range and stability. The new antenna is a low cost patch antenna with an approximate maximum 5dBi attenuation. In addition to this we progressed on track with our schedule, continuing testing for the RESQubes, working on the SLAM algorithm, creating prototype RESQube shells from PLA and TPU, working on the RSSI, and conducting trade studies based on our testing results to update our model. Along with this we have done some preliminary testing on compatibility between the camera, LiDAR, and Jetson by testing if they can communicate and recognize each other.

Risks and contingency: The main concerns we see with our future implementations is the size and weight allocation of an additional antenna to each RESQube. We are planning for patch antennas currently and are in the process of testing them, however if these are insufficient in supplying our needs there is a possibility to include a omnidirectional rod antenna. In our design, however, we have ensured that this worst case scenario would still ensure we are achieving our MVP for the size and deployment of the RESQubes.

Below we have attached a picture of our testing platform for the RESQube we are currently using to test mesh capability and communication. The goal was to keep the system as simple as possible to test capabilities piecewise.

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.