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.