Posted on

Team Status Report for October 18

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.

 

Posted on

Jeremy’s Status Report for October 18

Since the last status report, the main thing that I have worked on is the design for the SLAM subsystem and for path planning (both global path planning and local path planning). I finalized the overall design, with scan matching-based SLAM used similar to Hector SLAM, and with Dijkstra’s algorithm for global path planning and TEB for local path planning. These designs are described in detail in the Design Report, which I worked on significantly along with the rest of the team.

My progress is on schedule at the moment, with the goal from before having been to have completed the design at this point. I had also wanted to have an initial version of the software working by this point, but that was not feasible yet since the team and I were still working on finishing the design and figuring out the details. I did however find GitHub pages with code for both Hector SLAM that we can use as a starting point for SLAM, and for TEB which we can use as a starting point for local path planning. These are shown in the Design Report.

By next week, my goal is to have these initial versions of the code running correctly on the Raspberry Pi. This will involve working on the software and setting it up in the ROS environment. Additionally, I will order the necessary hardware for these (mainly just the Lidar scanner, plus any wires needed to interface with the RPi) and have this connected to the RPi.

Posted on

Soren’s Status Report for Oct. 18

I spent the past couple of weeks primarily on the design report and on finding solutions to a few of the outstanding gaps in our design. First, I decided that we should use the on-board Raspberry Pi WiFi to allow our robot to communicate with the the users (i.e. rescue team) of our system. Second, I was searching for some way to convert the CVBS analog video signal that comes out of the thermal camera model that we’ve picked out for our design into a digital form that can be used by our Raspberry Pi for image processing. I have found a component that should accomplish just this.

I am slightly behind schedule for the thermal image processing portion of the project. Next week, I need to finish testing the first few approaches to thermal image processing that we are trying using thermal imaging data available on line, and determine if other techniques should be used to solve this problem (such as a HOG type algorithm) as discussed in the design review report.

Posted on

Andy’s Report for October 18

For the week before the fall break, I completed the design for the robot base and computation unit and finalized the design report with my teammates. I have worked out most of the technical details, including the wiring plan and the control program for the mecanum wheels. These details are documented in the design report, and I have provided well justifications for them.

The only remaining issue is the powering plan. While the current design should work in terms of voltage requirements, I am not fully confident about its feasibility since I have limited experience with circuits and batteries. I plan to work with my teammates to refine and verify the powering plan in the coming weeks.

Overall, I am on schedule, with only a slight delay caused by the power system uncertainty. It should be easy to catch up once the issue is resolved. My next steps are to assist in implementing the SLAM and path planning algorithms and to begin developing the control program. Completing these components will help us determine the final configuration of the computing unit as soon as possible.

Posted on

Soren’s Status Report for 10/4

This week I delivered our group’s design presentation and continued working on our algorithms for detecting people given infra-red imaging data. Overall, on this portion of the project I am on track as next week I plan to test the accuracy of the algorithms that we have so far using IR imaging datasets online.

This week I also began thinking about how our system will represent, store and keep track of what the robot’s surroundings are (some of the more detailed aspects of the path planning portion of our design). I think in this portion of the project, we are somewhat behind as it was pointed out to us in the design review that we have not considered some of the important details in the path planning portion of the project. To help move things along here, it seems likely that I will take up part of this portion of the project to work on in addition to IR data processing. Next week I will work on a detailed design/plan of how our system will take in information from the Lidar scanner about its environment, store the information it has about its environment, and use that information to navigate (as well as the exact policy/way in which it will navigate), and what functionality we may want to include in this portion in addition to just how the robot will explore a building’s floor/rooms.

Posted on

Andy’s Status Report for October 4

This week, I worked with my teammates on the design review presentation and continued developing the vehicle design. After evaluating different options, I decided that a chassis equipped with magnum wheels would be the best foundation for our vehicle, as it should provide strong mobility and maneuverability. Overall, I am on schedule.

My next step is to explore the motor controller and control algorithms, focusing on how to make the robot turn or rotate effectively. By next week, I plan to finalize most of the design, order the required parts, and complete the design report.

Additionally, I looked into another robot platform called iRobot Create. It is a highly programmable and capable system, but it is no longer widely available. The inventory currently lists iRobot Vacuum models, so I plan to investigate whether they can serve as a substitute. If they are suitable, I may adjust our vehicle design accordingly.

Posted on

Team Status Report for October 4

The main risk at this point is that we are still working on the details of how many of the systems will work, and we aren’t yet sure what problems will arise as we try to implement our designs. For example, we are still figuring out exactly how the pathing algorithm will work and where the robot will decide to go (though this will come into more focus once we have an initial version of the SLAM system completed so we can see exactly what the input to the pathing algorithm will look like). To manage these risks, we plan to start implementing our software on the actual Raspberry Pi so we can refine the designs by seeing how they will be implemented. We have ordered the Raspberry Pi and it is ready for pickup from the ECE Inventory, so we can get it first thing Monday morning.

Last week a lot of the design was uncertain, but we have worked a lot more on the design for the design review presentation. There have not been any major changes to the design since the design review presentation. However, we are still working on refining our design and going into greater detail for the design review report. There have also not been any changes to the schedule since the design review presentation.

Posted on

Jeremy’s Status Report for October 4

This week I worked on the design for the SLAM subsystem. After doing some research, I determined that a Scan Matching-based 2D Lidar SLAM method would probably be the most effective for our use case. I read the papers A Review of 2D Lidar SLAM Research (Yan et al. 2025) and A Flexible and Scalable System with Full 3D Motion Estimation (Kohlbrecher et al. 2011) as part of this research. The first provided explanations of many SLAM systems which I used to evaluate which would be most effective for our use case. The second went into greater detail on a specific Scan Matching-based algorithm called Hector SLAM, which they also provide in open-source software. I think that this is a good initial design for our SLAM system, and that the open-source software can be used as a starting point for our software. I also worked on the slides for the design review presentation.

My progress right now is on schedule. My goal was to have an initial design for the SLAM algorithm by the end of this week, which I think I have accomplished.

By next week, I hope to have completed an initial version of the software that will demonstrate that the design is feasible, and to begin working on implementing it on the Raspberry Pi. I think that this should be doable by using the open-source software for Hector SLAM as a starting point for our software for the SLAM system.