This week, other than completing the final presentation, we all had exams to prepare for and other work that made us unable to make much progress. We plan to make a final sprint next week when we can devote all our time and focus to this class.
Tyler’s Status Report for 4/25/26
This week, I didn’t have much time to work on this project due to exams in other classes. I spent a little bit of time diagnosing one of the rover’s overheating problems and pinned it down to another bad sonar module. Once my finals are done, I’ll be spending time finishing up the movement fine tuning/testing of the swarm.
Team Status Report for 4/18/26
This week, we worked on integrating all components and the 3D printed cases. We now have 2 fully functional vehicles and one with some issues. The one with issues works for a while then restarts itself and has sometimes seemed to overheat. We are looking into the wiring and switching out components for backups to try to solve the issue. Other than that, we have been working on getting movement solid by tuning the PID motor controls. We also have basic target detection, so we have a basic wander and detect framework in place. We plan to add a lot more complexity and robustness over the next few days as we approach the final demo.
Tyler’s Status Report for 4/18/26
These past two weeks, I have 3D modeled and printed the cases for the vehicles and target for the camera to detect. I’ve worked on getting a final version of the operating system with the cv2 library included and all the systemctl scripts in place. Most of the time was spent fitting everything into the cases and fixing hardware issues that arose when reconstructing the cars in the cases. I also worked on refining the camera system to work with the new target using more advanced cv2 techniques to reduce noise, amplify the real color, and detect circles.
Tyler’s Status Report for 4/4/26
This week, I worked on integrating Jacob’s movement code with the rest of the system, changing the blocking while loops to an update-based system so that UART messages can still be read while the PID is working on the motors.
I also got started on 3D modeling the frame that will enclose all the electronics. I found a model for our car’s wheels and chassis online and am modelling the enclosure around that model.
Team Status Report for 3/28/26
Our team started this week by finishing the building of our first vehicle.
Isaac spent some time on building a second, but we are waiting on level shifters before the second is completely done.
Tyler worked more on the UWB systems, getting ready for us to have and use distance measurements during our demo.
Jacob worked on the vehicle movement, using PID on the data from the motor encoders to drive the vehicle in a straight line and rotate by a variable number of degrees.
Overall, we are on track. We are meeting tomorrow (3/29) to make sure everything works together for the demo, with high hopes due to the fact that everything is working individually.
Tyler’s Status Report for 3/28/26
This week, I spent a lot of time de-soldering and re-soldering the uwb boards to put in the new headers that give better connectivity with the pi and the rest of the car.
I also worked on the UWB subsystem some more. I identified many problems and solved most of them, mostly having to do with the sdk I’m using to compile the UWB OS being outdated. I’ve had to introduce some workarounds to enable the I2C subsystem that exists within the actual UWB module on the dev board.
The end of the week was used to use the UWB behavior that is implemented to create our demo system.
Tyler’s Status Report for 3/22/26
This week, I rewrote a lot of the UWB code to use interrupts instead of polling to make sure we get fast response times. Faster response times should lead to more accurate distance results. Due to the complexity of our UWB dev board OS, this took a lot of time, mostly figuring out exactly what needs to be enabled in the config files and what SPI rate can be supported. I didn’t get nearly as much done as I had hoped, as the IMU isn’t yet working. But by refactoring the code I had and making it interrupt-based, I set the ground work to be able to make progress faster in the next few days.
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.
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.