Posted on

Team Status Report for 2/14

Refined Use Case: Urban disaster area search for a single operator

(Definition of Search: reducing the area a Search and Rescue Team believes there will be a survivor)

Our team has finished our requirements and our design that satisfies those requirements to fit this newly refined use-case. It looks very similar to what we displayed in previous posts, but with key considerations noted below:

We are keeping the two motor per arm implementation. While our emphasis is not on being agile anymore, it is still more desirable to get over rubble that will be very likely present than to be limited to what our wheels can get over.

We have moved away from needing to care as much about size, as our use case does not necessitate it to be that small anymore. However, we still need to be mindful of cost. But, this gives us room to have a larger battery, and overall better equipment.

We are not doing fancy things like having the robots attach or jump anymore, as cool as that would be, it is not feasible for our MVP (and Josh is not a MechE)

We are using UWB as our primary method of localization / sensing, and for that to function it needs anchors. Anchors need to be stationary, and you typically need at least 3 to have readings at cm accuracy (which we want as all error accrues over time). Therefore, a working system will need at least 4 functional robots (3 that stay still while the other moves). In initial testing and our MVP we only need two to move and prove the distributed system effective, the rest can be stationary.

Our UI will be visualizing the paths that our robots have followed, and give color to those lines based on their proximity to a person (our MVP will be using a stationary anchor not ascribed to a bot). We will not be doing complicated SLAM things.

Posted on

Joshua’s Status Report for 2/14/2026

I don’t have much to show for it again (well, I at least have the image below), but I have largely focused on learning how to use FreeCAD. Our design considerations are finished (see team post for details, also my personal relevant points are rehashed below), so now I want to port at least something over to CAD to have for our presentation this week.

We are keeping the two motor per arm implementation. While our emphasis is not on being agile anymore, it is still more desirable to get over rubble that will be very likely present than to be limited to what our wheels can get over.

We have moved away from needing to care as much about size, as our use case does not necessitate it to be that small anymore. However, we still need to be mindful of cost. But, this gives us room to have a larger battery, and overall better equipment.

We are not doing fancy things like having the robots attach or jump anymore, as cool as that would be, it is not feasible for our MVP (and I’m not a MechE)

Posted on

Brooks’s Status Report for 2/07/2026

Accomplishments:

This week, we all spent time nailing down our use-case and requirements, and the MVP which would meet these. Our group has been meeting after class this last week to talk about our design plans and potential changes we might need to make, especially after getting feedback from our proposal presentation. I also spent time familiarizing myself with the ESP-IDF and microROS. Overall, this week was mostly spent researching microcontroller options and how to use RF reflection for target identification.

Since we’ve narrowed down our project’s requirements and have decided to use microROS, Zigbee, and WiFi, I spent time looking at microprocessors which would enable us to use these.

Notes on microprocessors and DevKits for our requirements:

Microprocessor + DevKit Consideration Notes (1)
Microprocessor + DevKit Consideration Notes (2)

Progress and Schedule:

The project is on schedule so far, but to stay on track we have to finalize our design by the end of next week, earlier better than later. This will allow us to spend the remaining days in the week, or weekend, finishing our presentation slides for the design presentation. I feel like I am in a good spot regarding my portion of the design and am on schedule.

Hopes for Next Week’s Deliverables:

For next week, I want us all to work together to finish the design for a single bot. For myself, I want to finalize decisions on microcontroller devkits, and whether or not we need an additional antenna on board for signal transmission + reception. I’d also like to merge this with the rest of my group mates so we know where all of these components will sit inside the bot, in order to finish the CAD design.

Posted on

Team Status Report for 2/07/2026

Risks:

At the moment, we are working on the design of our robots and what sensors, actuators, and microcontroller we will need to make our system work. The biggest risk in jeopardizing the success of the project at this stage would be making poor design choices, as our ability to implement the movement, communication, and searching of our robots highly depends on the choices we make now. In order to ensure that our design includes the components needed for implementation, we’ve divided subsections of the system among the three of us which we are responsible for.  Josh is focusing on linkages, body, and locomotion. Adrian is responsible for ensuring we have the proper sensors for obstacle detection and SLAM. Brooks is responsible for the RF communications components, microcontroller, and target detection.

Design State:

Thus far, we haven’t had to make any changes to our requirements nor design, but we expect the possibility minor tweaks or adjustments to the design in the coming week as we begin to finalize our parts list.

Schedule Changes?

We have made no changes to our schedule. We are still planning to finish our design this week so we can begin ordering parts, and to prepare for the upcoming design presentation.

Photos:

Initial Drawing of CatomBot Exterior:

Posted on

Joshua’s Status Report for 2/7/2026

I had prioritized the ECE capstone in the previous weeks knowing I would be out of town this weekend and not have the time to spare. While I have not had as much time to do more tangible efforts, my spare time amidst my other obligations was often captured by design considerations or our individual carom bots and researching how others have done similar ideas. I considered this okay for now, and didn’t redelegate as I wanted to take time to really think things through before locking a final design in anyway.

FreeCAD is a software I am learning how to use to make our 3D printed housings and designs. I as the robotics major am most familiar with design, and have given semi-detailed plans for a mechy to cad, but before this I have not done much CAD myself beyond intro to Mechy freshman year. I am therefore going through tutorials to develop that skill as I think about our design in parallel.

What is the priority of the design? My primary consideration was in creating something with agility and speed. Agility to navigate rough terrain, and speed to match the urgency of a search and rescue operation. It is also necessary to consider how either the robot will come back to the user, or how can we make the system so cheap we don’t care if some or even most can’t come back.

The design from our presentation last week (I can’t get the image working through my iPad, sorry, see the team status report post) is the base design I arrived at in the previous weeks, from which I am now refining. The rest of this post will give a brief look at what I have considered.

To enhance agility, I am considering incorporation of a spring / launching mechanism in the arms, where they store energy and release it to “jump”. (See https://youtu.be/daaDuC1kbds?si=DPnzXT5Hto2RL203 and https://youtu.be/xUUW6SYl_ak?si=parwDyRLWtX7nn9E for the general idea)

Our wheels to enhance speed do not need to be on the end. They instead could be around the middle of the arm. This leaves room for more easily attaching our catoms together, as now the ends are freed up again. It could also serve as padding for the catom similar to a door stop if the launch mechanism is incorporated.

The method of attaching catom to catom doesn’t need to use magnetic actuation. I thought at first that at the very least it will need a complementary connection mechanism. However, for our use case I don’t think so if we consider the alternatives. 1) a latching/coupling mechanism would require a level of precision that our catoms don’t have. It also would need a motor that either is on the end (which makes it harder to move the end effectors around) or it needs a shaft that runs through the arm. This is different than a magnet that may take similar space, as the shaft would be moving and potentially grinding on other components we want in the arms if we go the route of adding sensors to them. 2) if we don’t have a latch/coupling mechanism, then it will not be stable by default, and will require some constant force to keep any connection in place.

This is why after deeper consideration I still think a magnet is great, as it by default will be attracting the ends together to maintain connection, and the magnet doesn’t require movement to disconnect. This allows us to maintain low power, and smaller form factor as there are less parts to worry about, and it also gives it a larger life cycle since it isn’t wearing internals out over time.

Once these design decisions are finalized, then we can consider stuff like battery life and servo strength requirements. I have secured servos from robo club already to test, and coincells we can potentially use. I want to stress test servos running off a LiPo coin cell to see how they can handle a load. I also secured a board for Brooks to start running software tests on.

Finalizing the physical design by next week is my goal, but at the very least we need a finished BOM to start developing a PCB board to order. This means it may be okay to not have the design in CAD, but the decisions that lie as dependencies for our battery life and servos must be done by next week (more like Wednesday honestly) so we can have the BOM done next week.