Posted on

Brooks’s Status Report for 2/21/2026

Accomplishments:
This week my main accomplishments were determining the components needed to power both the microcontroller and the UWB SoC, as well as getting started with programming on the ESP32-S3 devkit we got a hold of.

Regarding power, our team decided to use a 2S LiPo battery which will give us a supply voltage of around 7.2V. Since both the ESP32-S3 devkit and the UWB devkit either run on USB or 5V supply, I picked out a suitable buck regulator from spark fun that is rated to supply up to 3.5A continuously which will be plenty to handle brief current spikes due to RF transmission.

As for programming on the devkit, I first made sure I was able to use the ESP-IDF for building, flashing, and monitoring serial output straight through my terminal:

Running Hello World from terminal

I chose to start with this so that if I encountered problems using the VSCode extension (the recommended way), I would have a better understanding of what was going on behind the scenes. I then moved to setting up and using the VSCode extension for set up so that I would have a proper development environment, as the extension makes the process of setting up your serial ports, setting the target, etc much easier or automatic:

Running Hello World using ESP-IDF VSCode Extension

Lastly, I made sure I knew how to properly debug and spent time figuring out how to use the extension to launch an OpenOCD server and begin debugging with JTAG and GDB. This step had some minor issues I had to sort through regarding which compiler was getting automatically selected by pressing the run and debug button, but after getting it all sorted I was able to set breakpoints and single step in GDB:

Debugging Hello World with GDB and ESP-IDF VSCode extension

Scheduling:

After the hiccups from the previous week, we are doing okay scheduling wise. We have finalized our BOM as a group and worked out the details of how all of our components are going to hook up (e.g. power) and which regulators or breakout boards we’d need. Also, I had planned on getting the development environment set up, which is mostly complete now with getting all the ESP-IDF things set up so I can now interact directly with the board. However, I was unable to get microROS set up. I tried using the micro-ROS component for the ESP-IDF but was having trouble flashing an example to the board this way and was unable to get this method to work and will need to continue troubleshooting or determine another way of running a micro-ROS agent on the board.

Next Week’s Deliverables:

In the next week I want to first get a micro-ROS agent publishing from the board first over serial, and then over WiFi UDP. In order to do this, I’m going to step away from trying the microROS component for the ESP-IDF and will instead be trying to get a normal ROS2 setup going on my laptop first, as I believe this may fix the issues I’ve been having with the component for the IDF.  I will need to create an Ubuntu partition on my Windows laptop as ROS2 requires a Linux environment, and then I can see if that fixes things. I know that other people have managed to get a microROS agent running on the board we are using, so I just need to figure out what method will work for us. Lastly, since we are partially limited by the work we can do until our components have arrived, my goal is to get a micro-ROS agent fully running on the devkit as a publisher with my laptop set up as a subscriber. Once we are able to publish data and read it on the laptop, I can start working with Adrian on how to connect the data we are getting from ROS to the boiler-plate UI he is working on.

Posted on

Brooks’s Status Report for 2/14/2026

Accomplishments:
This week, after our team narrowed the project scope from general search and rescue to urban search and rescue on a single building floor, we split responsibilities by subsystem. My role was to evaluate the viability of ultra-wideband (UWB) as a localization method to correct accumulated error from dead reckoning and to choose a UWB hardware path that we can realistically prototype within our timeline. I researched how UWB behaves in indoor, floor-level environments (multi-room layouts, reflections/multipath, and possible non-line-of-sight), compared integration options with a focus on practical bring-up and documentation quality, and ultimately decided on the DWM3001 as the module direction. While working, I made some rough illustrations regarding our communications stack and how it will work to explain my thoughts to the rest of my group.

Progress:
Overall, we are slightly behind schedule, primarily due to constructive feedback after our proposal presentation that required a meaningful restructure of the project goal. We shifted from a broad “general search and rescue” framing to a more concrete demonstration of the value of multi-robot search in an urban environment, specifically, a single building floor, so some of this week’s effort went into revising scope and re-planning deliverables. To catch up, we are locking the narrowed scope so we stop burning time on requirements, pushing to complete the BOM and place orders immediately to avoid delays in purchases, and parallelizing integration work using the development hardware we already have so software progress isn’t blocked while we wait for parts. My time this week reflects that split: roughly 4 hours on UWB research, 4 hours in group planning meetings, 2 hours on module comparison and selection, and 2 hours reading general communications/distributed systems/networking papers to inform our coordination assumptions.

Scheduling:
Next week, our team’s goal is to complete our BOM and have all parts ordered so the build phase can begin without further slowing our schedule. As for me, I plan to start hands-on work with the borrowed ESP32-S3 devkit to begin bringing up the core software environment and laying the groundwork for integrating our stack (including micro-ROS on top of FreeRTOS), and I will convert the DWM3001 decision into a practical integration direction—how we’ll interface the module, what data we expect to use, and how those updates will be used to correct dead-reckoning drift during our floor-level demo. I’ll also keep the communications graphic updated as the architecture solidifies so we have a clear, consistent reference for how robot-to-robot and robot-to-base interactions are supposed to work.