Team A0: Building tSAR

The main risk at this point is that we have not yet tested and integrated our systems, but we are hoping to have a full system initially working for our live demo in a bit over a week in order to demonstrate a mostly functional initial version of the project. To manage this risk we plan to start testing and integrating our systems as soon as possible (over the weekend and early next week) so that we have time to deal with unexpected issues before our initial project demo.

Since last week, there have been several minor design modifications in terms of the hardware and software that we will be using. We ordered an additional part for interfacing between the Raspberry Pi and the thermal camera, and a few more parts for setting up the physical robot. For software, we changed the SLAM and local path planning software that we will be using since our previously selected software was not compatible with current, maintained versions of ROS. We will now be using SLAM Toolbox instead of Hector SLAM, and Nav2 instead of TEB for local path planning.

The most significant risk for the team at this point is that we have not actually implemented very much yet. We have spent most of our time on design, and have not yet seen how everything will work in practice, so there could be unexpected problems that will arise. Additional risks include remaining uncertainty in the designs for the powering subsystem and for the global path planning algorithm.

There was one main change to the design since the previous status report. This has to do with obstacle detection for local path planning. Since the Lidar scanner may be too high off the ground to detect short obstacles, we determined that an additional sensor was needed closer to the ground for use in local path planning to allow the robot to avoid these obstacles. We decided to use an ultrasonic sensor since it is cheap and simple to use, while also being effective for the necessary task. There was enough extra money in the budget for this sensor, so the most significant cost is that it is an additional component to set up, which we believe we can handle since it should be relatively easy to use.

There have been many minor changes and modifications to the design since the previous status report as we have worked on the design more and added more details. The current design is described in detail in the Design Report. There have not been any changes to the design since the Design Report was completed.

One main risk we have now is the powering plan. The current powering plan is not guaranteed to work as none of us is an expert of circuits and batteries. We will work together on this later to resolve the problem.

Another risk right now is that we have not yet implemented or combined the system yet, so we don’t yet know what problems we’ll run into as we do this. In order to mitigate this risk, we plan to order the parts early this week and start connecting everything to the Raspberry Pi and the chassis. This way we will discover any problems that we might have with the implementation sooner rather than later.

Part A: Our design considers global factors in that we have designed our search and rescue robot to work for a floor of any building. This is why we have designed our robot to be versatile, in that it can discover the layout of the building and does not rely on the building having only a layout that is found in buildings locally. Additionally, our design does not rely on a floor plan of the building being available ahead of time, since for many buildings this may not be the case. This way, our design should allow the robot to be useful for buildings of a variety of architectures across the world, allowing the robot to be helpful in urban search and rescue in a building in any city.

Part B: Our design takes cultural and ethical factors seriously, especially when it comes to saving lives. In rescue situations, people naturally expect technology to be dependable, and it can be hard to accept if someone isn’t saved because of an error in a new system. That’s why we focus on making our robot highly reliable with a very low false negative rate as it should never miss a person in need. The robot is also meant to reduce the risks faced by rescue workers by handling dangerous tasks on their behalf. In this way, our project supports the shared belief that life of rescue workers is as important as people who need help.

Part C: Our design addresses the environmental concerns of keeping humans safe and out of harm from dangers that may appear in a building setting. Our project is also committed to a low-energy-consumption solution to the problem of search and rescue in a building situation; while this is intended primarily to allow our system to be as effective as possible by exploring as much building area as possible because it would not be primarily limited by power, this will also have a secondary effect of minimizing use of environmental resources, i.e. power. Finally, by allowing a rescue team to quickly locate and evacuate people at a disaster site, the process of containing the site to prevent dangerous substances from polluting or destroying the surrounding environment (such as in the event of a gas leak, or building fire) could happen much quicker as well, thereby mitigating environmental damage that could be brought along in such a scenario.

A was written by Jeremy; B was written by Andy; C was written by Soren.