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

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.

Posted on

Team Status Report for September 27

Our design has been significantly changed since last week as a result of difficulties with our previous design that led us to modify our use case. The main difficulties we encountered before were the cost of using multiple drones and that an affordable thermal camera would not be able to cover a large enough area with a high enough resolution. We did not think there was a way to address these difficulties while meeting the use case requirements and providing a project that would be helpful for our use case because our drone would not be able to cover enough area quickly while maintaining reasonably high detection accuracy.

Our new use case is to build a search and rescue robot for indoor use after an event such as a gas leak. This contains similar technical challenges of detecting people and of doing pathing, but avoids the problems we could not solve with our previous use case. We are still working on the design, and are currently planning on using a circular robot so that it can rotate easily, with 2D SLAM (Simultaneous Localization and Mapping) with Lidar to construct the environment to be used for pathing, and a thermal camera to detect people in the environment, but the design could change as we finalize it in the coming days.

The main risk given our change in use case is that we still do not have a complete design at this point. This is especially difficult as the design must be completed in time for the design review presentation on Monday. However this deadline does help to manage the risk in that we will be completing our design quickly in order to be prepared for the presentation. Our schedule has changed as a result of the change to our project, but has not yet been finalized as we are still working on the design. An updated schedule will be provided in our design review presentation.

Posted on

Jeremy’s Status Report for September 27

This week I worked on the design for the path planning aspect of the project. However, since our design pivoted towards the end of the week, my previous design for the path planning is no longer particularly useful, so I had to begin looking at entirely different path planning starting Friday the 25th.

My prior path planning algorithm design was for multiple drones to search a large, outdoor area. This design involved first partitioning the search area into equal-area sections that could be assigned to drones, and then plotting a path for each drone to its section that could sweep it out using a simple rectangular pattern. A slide I had made for the design presentation on this algorithm is shown below:

 

However, since we are moving towards having a robot on the ground explore an indoor building, this path planning algorithm is not applicable to our new use case because the search area will have far more obstacles and be in an unknown configuration. So, I have begun looking into Simultaneous Localization and Mapping (SLAM) and using pathing algorithms with that. The pathing will now have to be done onboard the robot rather than programmed beforehand, since the environment will be unknown at the start and determined in real time using SLAM. Based on some initial research, I am thinking that we will want to use Lidar for detecting walls in the environment.

The change in design has led me to be behind our original schedule since I had previously wanted to have the path planning fully designed and start working on implementation at this point. To catch up I plan to spend a lot of time over the weekend on designing the SLAM and new pathing, although with our design changes we will have to develop a new schedule for the project. By next week I hope to have fully designed the SLAM and path planning algorithm for our current project.

Posted on

Team Status Report for September 20

One significant risk for the project is that, in addition to the complexity of the individual systems, integrating the systems into a working product will also be difficult. To manage this risk we plan to coordinate well and complete the individual subsystems quickly to allow a lot of time for integration.

Another significant risk is that we need to find a way to do test flights of the drone. To manage this risk we plan on contacting testing sites and applying for use of them early, as soon as next week even though the drone won’t be ready to fly yet just to make sure we have access to a way to do test-flights.

Early on in the week, there was significant design development, refinement, and modification as we were working on the project proposal presentation. There have not been any further changes to the design of the system yet, and the current design can be found in the project proposal slides.

Posted on

Jeremy’s Status Report for September 20

The main thing I did this week was work on the project proposal presentation. Early on in the week I worked a lot on developing the slides for the project proposal, and then I also did additional preparation since I was the one giving the presentation.

Later on in the week, I also did some preliminary research on drone path planning algorithms. My progress is on schedule at the moment. By the end of next week I hope to have completed development of an initial version of the path planning algorithm we will use to program our drones.