This week I worked on space partitioning algorithm and rover movement based on coordinates. Rotations still need to be calculated by testing our motors with the new battery, and I plan on having it done for this week. For space partitioning, I have assigning partitioned spaces to rovers based on index done, but I still need to figure out a way to do this recursively so that it is scalable. I haven’t done as much as I wanted to this week, but I am caught up on schedule and this week I am expecting a more tangible progress.
Jacob’s Status Report for 3/14/26
This week, I worked on integration. I wired up the motors to the motor driver and the motor driver to the power bank and Raspberry Pi. I also wired up the IR sensor and added test code for all of these components. Here’s a picture! You can’t tell, but the motor is turning. We will be using lgpio (Python) as our GPIO library. After testing, I am concerned that the motors and frames we have are cheap and flimsy. Hopefully they last the duration of the project…
I am still on schedule. My ne
xt steps will be testing the motor encoders and the Raspberry Pi camera. The motor encoders aren’t yet attached to the frame, but I don’t anticipate that the encoders will require much code once they are attached. After I figure out the camera, I’ll write some basic target detection code.
Tyler’s Status Report for 3/14/26
This week, I worked on the UWB systems. Because we got a UWB development board, the board must be flashed separately from the raspberry pi, which ends up being more work than anticipated. I had to figure out JLink communication from my laptop to flash the UWB boards, and then augment the basic UWB board operating system to communicate with an RPi over UART. Fortunately, the UWB boards are able to connect straight onto the Raspberry Pi GPIO pins after some basic soldering. As of now, the Pi’s can send commands to the UWB boards to act as a transmitter or a receiver, and they are able to extract distance information from the messaging process with enough accuracy for our purposes. I wrote a basic program to poll for distances in a psuedo-“initialization phase” situation.
Next week, I want to start using IMU data to get localization and triangulation working. I am roughly where I hoped to be by the end of this week. I would like to be totally done with the UWB OS next week, with all the needed functionality flashed onto the UWB boards and any future UWB development taking place as the RPi sending UART commands to the board. Some integration between UWB and vehicles should happen next week or the week after.
Isaac’s Status Report for 3/7/26
The week before spring break, I mainly worked on writing the design report and building our first rover with the team. As we received our main parts for the rovers, I should be able to finish basic motor control of the rovers with the Pis. There has been some shipping delays that is impacting our progress, but we are still not too late on schedule. I am planning to finish the rover movement and begin working on convergence protocols before the other parts arrive.
Jacob’s Status Report for 3/7/26
Before spring break, I worked with the team to finish up the design report and I worked on assembling a vehicle with the team. I also added some driver code to the group repository for controlling the motors with the L298N motor driver. Due to some shipping delays, I did not get to testing all of the sensors/components yet. This was scheduled for the week before break as well as the week after break. I am currently still on schedule and will be working on integrating the sensors next week.
Team Status Report for 3/7/26
This week, we mainly focused on finishing our design report and assembling the first rover as a group. Due to shipping delays, we couldn’t get the UWB’s to work on them over spring break. Since communications was our next task, this did set us back and we will have to do more next week to catch up. We now have our first rover built and ready for applying our algorithms, so next week we will handle basic movement of the rover and communication between the rover and a test RasPi over UWB. We hope to have basic movement, coordinate calibration, and space parameterization/segmentation done by the end of next week.
Our product solution will fit the project needs with considerations of global, cultural, and environmental factors in the following ways:
Part A: Global Factors
With regards to global factors, we seek for our solution to work regardless of the technical education of operators. Due to our project’s autonomous nature, it would not take a highly skilled individual to deploy our rovers. Additionally, our solution doesn’t require any infrastructure to be used in a new areas around the world. They are able to be brought to a site and deployed instantly and will coordinate themselves regardless of how they are set up with no need for a programmer or engineer on site. In this way, the global issue of education inequalities will not be a barrier of use.
In addition to education inequality, our solution also keeps in mind global financial inequality. We sought to make our solution affordable. With each unit under $100, this technology is not expensive to acquire, allowing for large swarm sizes at low costs.
Part B: Cultural Factors
Cultural factors play a significant role in how our solution will be used and perceived. A major difference from traditional search and rescue is that our solution uses autonomous vehicles rather than human responders. It is important that our solution is very simple to set up and use so that any community could incorporate our solution, no matter what technical background or infrastructure. Additionally, many cultures have concerns about flying drones regarding safety and privacy. The use of ground-based vehicles reduces these concerns so more cultures would be open to adopting the solution.
Part C: Environmental Factors
Our solution is designed to minimize the environmental impact of search and rescue operations. We use small, battery-powered robots to search. The lightweight frames allow the vehicles to be more power-efficient and also have the benefit of disturbing the environment (soil) less than larger search options like ATVs. Additionally, our solution does not require installation or maintenance of any infrastructure in the search area, so this reduces the direct impact of our solution on the environments it is used in. This is especially important for sensitive or protected environments like national parks.
A was written by Tyler Weed, B was written by Isaac, and C was written by Jacob.
Tyler’s Status Report for 3/7/26
Due to shipping delays, I was unable to get the UWB’s in time to work on them over spring break. Instead, alongside the design report due last week, I worked on assembling one of the rovers and on OS duplication. Starting a new car once one is created should be very simple. Now we can focus all our efforts on testing one car and using other communication modules to test it, knowing that the behavior of one car can easily be ported to another. Much less was done over this period week than I hoped due to the UWB’s arriving late. We hoped to have the comms done by today, so we will have to push that to next week. Although we are behind schedule, if I can get basic communication and the initialization communication protocol done by next week I’ll be back on track and even slightly ahead of schedule.