Posted on

Brooks’s Status Report for 03/14/2026

The main work I did this week was completing the task of getting microROS and ROS2 completely setup as well as reading a lot of documentation for the Qorvo DWM3001CDK module. Regarding the ROS setup, I was able to successfully publish an increasing integer over WiFi from the ESP32S3 DevKit and then have a ROS agent on my computer receive it. This means we now know we can successfully publish UWB ranging information once we are able to connect the ESP32S3 to the DWM3001CDK.

Running microROS Agent
Serial Output of ESP32S3
ROS2 Topic: int32_publisher Talker
ROS2 Topic: int32_publisher Listener

As for the documentation for the Qorvo DWM3001CDK, I had previously had problems finding the documentation needed to begin programming on the board as the website only provides a simple product brief. However, after we received our boards this week, I requested the SDK from Qorvo which, after unzipping, I found contained all of the documentation we would need to work with the product. The SDK includes a firmware version they call the “UCI” version which has an API for sending commands for initiating TWR sessions. Given that we don’t want to have to write custom firmware for the UWB modules, this firmware version seems to fit our needs the best and will be the firmware I plan on using for implementing the pipeline between each ESP32S3 and DWM3001CDK. I was able to successfully start the board on this firmware and have it search for other UWB modules, but I did not run another module at the same time because, at that stage, I just wanted to see that I could get one working.

DWM3001CDK Initiation running the UCI Firmware
Example Ranging Output from the DWM3001CDK

I am not yet behind on schedule, however I now only have three days to complete the pipeline between the UWB modules and the ESP32S3’s. Now that I know what I have read the necessary documentation for interacting with the DWM3001CDK, I know that I have to write a library for serializing command messages from the ESP32, deserializing the responses from the DWM3001CD, and then packing that into a format to be published as a ROS topic that will be consumed by the UI Adrian is implementing. I plan to spend most of tomorrow working strictly on getting this up and running so that Adrian is no longer blocked by this task.

In the next week, I hope to complete the basic implementation of the ranging pipeline so that I can work with Adrian to begin connecting real ranging measurements to the UI. Additionally, I will begin working on the locationing / global frame formation using the completed ranging pipeline.

Posted on

Joshua’s Status Report for 03/14/2026

All our parts came in! (minus H-Bridge) With the parts in hand, it is much easier to come to a complete arrangement of what our system will look like.

This post will give a play by play of each components update, here’s the electrical chart again for reference:

Physical Connections:

Battery Connections: While RoboClub had batteries, we need to connect them to the rest of our system. First step is getting some wires with female tamiya connectors. the Tamiya blocks were available in RoboClub, but I had to strip and crimp some wires to them for us. See below. (While we don’t need all of these right now, it felt inefficient to just do one and leave the rest as a task for later)

The next step plan for each of these is to t/y-split them into their own step down and H-Bridge components. H-Bridge isn’t here as needed, so we will do that later. No impact to critical path.

LiDAR Connections:  Cord was provided in the purchased kit. They easily plug into the ESP pins.

IMU: the LiDAR pack had extra wires displayed, so I had initially hoped I would be able to repurpose them, but unfortunately we cannot, as the LiDAR is SPI compatible, which means it has extra wires and is not a purely I2C connector with only 4 (doesn’t fit into the IMU plug). Therefore I need to make new wires.

UWB: UART connection to the ESP is being handled by Brooks, seems to be going well.

H-Bridge: Problem was caught upon closer inspection of this choice once I had all our parts in hand. Our current option takes 5V for it’s control input, which is problematic for our ESP 3.3V option. This does not impact critical path, as other components have sufficient work to complete amidst reordering.

Drivers:

Battery: No drivers needed for battery connections.

LiDAR / IMU: Drivers will have to be made by us (me lol), I2C protocol will use a library for data package delivery and initialization.

UWB: Again, Brooks is largely doing this.

H-Bridge: Pivot to new component means we can’t do this yet, but it will need a driver.

Housings:

While considerations have been made (and standoffs/screws acquired for some components from RoboClub), I believe it best to have our electronics working and wired before I build housings for them. Evidence of this being a good decision already is our H-Bridge change. While components are very unlikely to change now (I am fairly confident we won’t), I would like to evaluate things like how far the LiDAR can actually see for position and placement considerations.

Next Steps:

Our critical path is getting strained. I anticipated this, and as Adrian has limited work he can do before this is done (and is the subject to which this strain effects), I have asked Adrian to help with the effort of this integration.

Posted on

Brooks’s Status Report for 03/07/2026

This last week I continued working on getting microROS and ROS2 working on my machine and on the ESP32. Since ROS2 is not well supported on platforms other than Ubuntu, I had to spend a while getting my dual-boot setup to work but I finally got it all set up. After I had my Linux environment setup, I spent some more time researching the setup for microROS on an ESP32 and found that I had to install the older v5.2.6 version of the ESP-IDF. Then, I found out that the ESP-IDF VS-Code extension is bugged on the snap version for VS-Code (the one you install from the Ubuntu app store) so I had to get the .deb package from the VS-Code website and install it using apt. That finally got everything to work on the ESP-IDF side. Then, I was able to install and use the Jazzy-Jalisco version of ROS2 for Ubuntu and was successfully able to create a ROS publisher and subscriber with the subscriber reporting back all the published information. So, in a nutshell, I got the entire development environment back up in Linux and was able to get ROS to work just on my laptop.

Progress is on schedule, I said that I would have been able to figure out how to have a microROS client running on the ESP32-S3 by the end of tomorrow, which works perfectly as that should all be straightforward after doing all the required setup this last week.

For next week, I will hopefully be able to implement the two-way ranging pipeline between an ESP32 and a Qorvo DWM3001CDK. I say hopefully as this will depend on whether or parts do in fact arrive next week with ample time to finish this step. We ordered the DWM3001CDK kits from Digikey last week so they should arrive in time for me to complete this deliverable. Until the parts arrive, my plan is to help my teammates with their deliverables as needed and try to find more documentation for the DWM3001CDK. In particular, I did not see a software/programming guide for the board on the website so I’d like to find documentation for how one interacts with the board. If I still have extra time, then I’d like to start writing the C code for performing trilateration as this can definitely be done without having the components yet.

Part B: Please write a paragraph or two describing how the product solution you are designing will meet a specified need with consideration of cultural factors. Cultural factors are encompass the set of beliefs, moral values, traditions, language, and laws (or rules of behavior) held in common by a nation, a community, or other defined group of people.

Our project is a small multi-robot system designed to assist with urban search and rescue operations by quickly exploring collapsed or hazardous environments where sending human responders would be dangerous or slow. While the system’s design first and foremost addresses the need for faster and safer disaster response, cultural factors can influence how our project should be designed and deployed. Disaster response can involve coordination between different agencies, communities, and sometimes international teams, each with their own norms, communication practices, and operational rules, i.e. cultures. Our design prioritizes simple operation and clear reporting of information via a simple UI so that responders from different backgrounds can easily integrate the system into their efforts. By keeping the system accessible and easy to operate, the design can help ensure the technology can be used effectively while respecting the expectations and procedures of the communities it would serve. If time permits, our design could further address cultural factors and differences by providing different language options for the UI
Posted on

Team’s Status Report 03/07

Design State:

The largest point completed was our design document, in which we didn’t necessarily make a lot of changes to our design, but we did finalize our particular parts/algorithms to use to satisfy our design.

All together, we refined our Design Requirements using detailed Use Case Requirements (see our design doc). With these linked, all of our design decisions are much more easily justified, and clearly purposeful. Also, Josh picked and ordered all final parts and Adrian researched and decided on the frontier-based exploration strategy. (See their respective posts for details)

Because we got access to an ESP early on from roboclub, Brooks has been continuing work preparing code we can port over to the incoming parts that will work with our system.

Risks:

The current critical path is getting our parts. All parts have been ordered, so it’s just a matter of waiting, but Brooks can’t test certain aspects of his work on the UWB module until he has that in hand. Josh also can’t test his housing designs until parts are here. Then, Adrian can’t test his algorithms in the real world until Josh has completed a full prototype with parts.

A risk that also comes with this is that some parts may be dead on arrival. However, since we have multiple parts for multiple bots, but only need one of each to start, this risk has minimal effect. A bigger risk is if the parts don’t function as needed, but substantial effort has been made to evaluate the parts being used, and all vendors are trustworthy, so this risk has hopefully been mitigated.

Schedule Changes:

Despite waiting on parts, progress is steady and on schedule, as we all have work we are doing while waiting.

Global/Cultural/environmental considerations

As described for this particular report’s rubric, we have split these considerations between us and appended our considerations to our individual status reports. Part A was written by Adrian, Part B was written by Brooks, and Part C was written by Josh.

Posted on

Adrian’s Status Report for 03/07/2026

The week before break, I focused primarily on finalizing the user interface architecture, the autonomous exploration algorithm, and the local navigation strategy.
The UI centers around a dynamic 2D map display, where the operator’s position acts as the origin of the global coordinate system, and all robots are rendered relative to that frame. The interface will visualize robot positions, exploration coverage, and detected targets to provide a clear situational overview of the mission. The search coverage visualization will use a sparse occupancy grid heatmap, allowing the operator to immediately see which areas have been explored and which regions remain unknown. This visualization approach ensures that the operator can quickly assess search progress without requiring detailed SLAM maps.
Additionally, I deeply researched the frontier-based exploration strategy, which directs robots toward the boundaries between known free space and unexplored regions. This approach maximizes information gain and naturally distributes work across multiple robots. Frontier points will be detected from the occupancy grid and clustered into frontier regions, allowing the system to assign exploration targets to different robots while minimizing overlap in search paths.L. Lu, C. Redondo, and P. Campoy. “Optimal
frontier-based autonomous exploration in uncon-
structed environment using RGB-D sensor”. In: Sen-
sors 20.22 (Nov. 2020), p. 6507. url: https://www.
mdpi.com/1424-8220/20/22/6507.To support safe navigation during exploration, I finalized the design of the local obstacle avoidance system using the Vector Field Histogram (VFH) algorithm. While the frontier algorithm determines where robots should move globally, the VFH controller will handle real-time navigation decisions by utilizing LiDAR data. Obstacle measurements are converted into a polar histogram representing nearby obstacle density, which allows the robot to choose safe steering directions while still progressing toward its assigned frontier target. This layered approach enables robots to react to obstacles dynamically without needing to constantly recompute global paths.

Progress remains on schedule, and the next steps will involve implementing the 2D simulation test suite and integrating the autonomous exploration algorithm within the simulation environment. This phase will focus on validating the algorithm’s performance under various conditions to make sure the robot behaviors, such as frontier detection, obstacle avoidance, and coordinated exploration, operate as expected.

Part A: … with consideration of global factors. Global factors are world-wide contexts and factors, rather than only local ones. They do not necessarily represent geographic concerns. Global factors do not need to concern every single person in the entire world. Rather, these factors affect people outside of Pittsburgh, or those who are not in an academic environment, or those who are not technologically savvy, etc.

Our CatomBots system addresses global factors by prioritizing accessibility and affordability in disaster response technology. Search and rescue operations occur worldwide, often in regions where expensive robotic solutions are financially out of reach. By keeping the cost per bot under $200 using accessible, commercial off-the-shelf components, our design ensures that emergency response teams globally can deploy a scalable swarm to rapidly map hazardous environments and locate survivors. Furthermore, our intuitive, web-based UI is specifically designed to be easily operable by first responders who are not necessarily technologically savvy or from an academic background.

Posted on

Joshua’s Status Report 3/7/2026

Overview:

Firstly, I focused a lot on refining our requirements further, and made a proper outline of all of our Use Case Requirements in as concise of a way possible. I then led a call where I and the team took all of our previous considerations and made Design Requirements directly tied back to these Use Case Requirements. I then transferred this over to our design doc in even more clear language, along with ensuring our Design Requirements had quantitative metrics whenever possible. I also then made most of the tests for our V&V section that satisfied all these design requirements.

Then, with that finished, the main order of business was evaluating all of our parts that we would use again, now that we know what types of parts we would use. While some of the options we picked ended up being our final option, there are a few new things I found. For more depth, see our design document and our trade studies. Most of that was me. But as an overview, I’ll mention some of the important ones:

Part Evaluations:

First up, the IMU. Our initial choice IMU was good for lower power consumption, but considering we are using fairly motors, with significantly more current draw than most sensors, that isn’t necessary for our use case. With some research, I landed on the current robotics industry standard, which is a little more expensive than what we had, but since we had room in the budget for it, it was a clearly better option we should and will use.

Next, the ESP. Brooks and I already put a lot of thought into this,  so it was just finding a good price and vendor. One few new considerations was that the one we had has a camera with an IR filter, but because we are in the dark this is not actually ideal for us. However, we can take this filter off manually, so it is okay.

We decided to use motors instead of servos (thus also needing an H-Bridge), as we don’t really care about encoder type feedback, and since we have an IMU we don’t need the encoders to determine speed loops. (we will need to be cognizant of this fact while implementing the control loops, but it is not inoperable). We don’t need fancy, just reliable, so our chosen options are simple and robust with good user feedback.

While reconsidering UWB for our use case of locating survivors again, infrared and heat-sensing came up as possible replacements. We decided against this because it doesn’t allow for us to locate people out of our line of sight. If we needed a line of sight always to determine if a portion of space is not worthy of a SAR team’s investigation, this would significantly slow our system down, and also potentially miss people. UWB can “see” through walls, which is then clearly better, also helps to mitigate the fact our robots won’t be able to reach all locations.

LiDAR doesn’t get cheaper without significantly losing quality than the one we found, so it’s great, not worth discussing further.

Here’s the finalized electrical diagram with our adjustments:

Next Steps:

All of our parts are submitted for order, and I have started designing how our components will all fit together in housing. To keep up with the schedule, I need to have these designs done and prototype housings ready for print by the end of this week. Regardless of if parts come in, prototypes should be completable using online models / spec sheets, and are thus still on schedule even if parts are delayed.

Environmental Considerations:

Our robots are disposable, in the sense that they are cheap enough that a search and rescue team would not be concerned if they lose a robot or two. However, this means we should consider how our robots may impact the environment when lost, as well as possible interaction with the survivors (although this is minimal it should be considered).

One aspect of this is our batteries. If we were to use LiPo, that would not be very safe to just leave in the environment, especially among such a hazardous environment where the batteries could be punctured. Our batteries are instead NiMH, which while not as performant, are safer and more durable, which is great for this application and consideration.

For the body and wheels, which is the largest portion of mass of our system, our solution approach uses PLA plastic. While there are claims and an argument to be made that some 3D print PLAs are less impactful, it still is not great for the environment. However, once designed where rapid iteration is not necessary anymore, PLA can be exchanged for more environmentally friendly materials.

The rest of our electrical components are difficult to address, but all sensors are quite small, and the non-dev version of our UWB board would also have less impact once consolidated away from using the dev board.