https://drive.google.com/drive/folders/1isZmPOO2c6-z1lyu5qdEl4IOM93BYcho
Team Status Report for 04/25/2026
This week, our team was able to successfully integrate all the live sensors, ESP32 camera stream, and teleoperation onto the catombot (shown in the video link).We were very relieved to get the robot moving by slightly changing the physical design and gear size of the motor’s gear, so it has enough torque to spin the gears and hence the whole bot. Further details are explained in Josh’s status report. These physical improvements, combined with Brooks’s implementation of the motor-subscription logic for the ROS velocity topic, allowed us to verify a full control loop from the base station to the physical robot. Adrian further refined this experience by stabilizing the UWB position stream by implementing a stationary deadband to remove 5-10 cm of jitter and integrating the live ESP32 camera feed into the user interface.
Teleop robot with sensors and a camera with minimal jitter
While teleoperation is functional, the autonomous search algorithm and navigation framework still require significant tuning, specifically regarding IMU calibration to align LiDAR point clouds and prevent drift during goal-seeking. Looking ahead to next week, we will focus on scaling the system by printing and soldering a second robot, refactoring the UI and UWB code to support multi-robot communication, and finalizing the integration of autonomous frontier exploration.
Adrian’s Status Report for 04/25/2026
This week, I improved the live UI’s robot position stability by adding stronger filtering to the UWB position stream. Previously, when the robot was stationary, the displayed x, y values would still drift by 5-10 cm amounts, causing visible jitter that messes up the robot’s UI location on the map. I tightened the stationary deadband so tiny UWB changes are held at the previous position, which makes the bot marker appear much steadier when the physical robot is not moving.
Teleop robot with sensors and a camera with minimal jitter
I also began implementing the autonomous navigation for the robot by adding a live autonomy control path that converts selected goals or frontier targets into geometry_msgs/Twist commands and publishes them to the same ROS topic used by teleoperation (/catombot/id_1/commands/velocity). This means the physical robot can be controlled through the existing firmware path since the ESP32 already subscribes to that velocity topic and applies linear.x / angular.z to the motors. However, I still need to make several fixes, including but not limited to making the IMU have proper calibration so the point clouds are always in the same direction as the robot’s front LiDAR view, and also ensuring the robot doesn’t drift too far off from the target and frontier cells.
Robot moving autonomously (not fully working tho)
For next week, I plan to address those issues as well as refactor the UI to accommodate 2 robots doing the search and creating an alert when the tag is detected.
Joshua’s Status Report for 4/25/2026
Teleoperation Success!
There were two issues that I ran into upon integration testing the frame housing that prevented locomotion:
- The space between the front plate and the wheel attachment piece was too large, and it caused the wheel to twist and get caught on itself when spun. This was fixed by increasing the thickness of the bottom front plate ring to hold the wheel piece down. I thought having more would be okay with the wheel holding it on the other side, but then it would have been more friction as the wheel being the primary method of holding it in place would drag much more.
- The gear train required too much torque from our motors. As a run down of the diagnostics: a) the friction was minimal with PLA on PLA (after fixing issue 1). b) The rods we used were very form fitting with the gears spinning very nicely (I had made another little piece with various hole sizes to test which would be best before making the full print). c) The spacing between gears was all correct, as the gears could spin well using our hands, but it was difficult to spin them. So the solution for this was to change the gear ratio between the gears. I made the motor gear smaller, and the corresponding one larger to match, so the design didn’t have to change much and we could still use the rest of the print we already had.
Old: New:
(there are also a few other issues that were addressed, that weren’t strictly necessary, but just make the bot better to work with. 1) Some holes were hard to screw into, so I made them slightly larger. 2) the sensor frame holder broke, so while duct-tape does work, I went ahead and made the frame a little thicker with more support. 3) the 3D model from online didn’t match the motors perfectly in length, so the snug fit works, but is slightly misaligned and required some physical *ahem* adjustments to mitigate that.
And now it works!! We have minimal media space for our website, so linked below is a full teleoperation integration test over WiFi using our keyboard and ROS topics:
Next Steps
Mainly, print our second bot with the now fully verified design. Then as that prints, also to help the team in refining our algorithms for the actual movement (and getting our actual full system documentation together). At the moment, it just maxes the voltage output forward, backward, left, right based on arrow key presses. This isn’t too conducive for autonomous or waypoint following. We have begun this process already, and Adrian talks to it more in his report.
Brooks’s Status Report for 04/25/2026
This week I was the one to give the final presentation for our project. I also worked with my other group mates to finish assembling the final rendition of a catombot once Josh’s final print had finished. Last Sunday, we found that the initial design of the gears required too much torque for the motors to move themselves, but Josh was able to quickly redesign them which ended up being successful. Once we determined that the new gear design was working, I implemented code for tele-operating the motors via commands on a ROS topic. Essentially, the robot subscribes to a velocity ROS topic to which the base station can publish commands that the robot will use to drive the motors. Adrian was able to add functionality to the UI where a user’s arrow key inputs result in the corresponding velocity commands being published to the ROS topic. So, we essentially can now fully tele-operate each catombot.
Our progress is definitely behind at the moment as we approach the deadlines for submitting our final poster and final report, as well as preparing for the demo. We still need to print the housing for another robot as well as solder all the necessary electrical connections so that we can have at least two robots for the demo. Additionally, we still need to get the robot running the autonomous search algorithm, translating search outputs to motor movements, and then test autonomous searching. After this, we also need to refactor some code in the UI and in UWB communication to allow for multiple robots to be used by the system, as our previous work has all been done in order to just get a single robot working.
In the next week, my job will be to fully solder all the electrical connections for a second bot and get UWB locationing and two way ranging working in the context of two robots who are initiators, who will need to both be able to communicate with each anchor as well as the survivor tag. Finally, I will work with the other group members to finalize integration of the system and to finish the poster board, final report, etc.
Adrian’s Status Report for 04/18/2026
This week, I have implemented smoother bot motion on the map and a working camera feed in the user interface. The firmware now filters UWB range measurements per anchor before trilateration, which cuts noise and occasional bad ranges without making the solution sluggish, and I increased how often pose is published so the base station sees fresher samples. On the UI side, I added a light stationary jitter gate so the marker stays put when the robot is actually still, and interpolated pose on the display refresh loop so motion looks continuous between sensor updates instead of stepping at the raw update rate. Together, that gives operators a stable icon when idle and fluid motion when the bot moves.
For the camera, I closed the loop from the robot’s HTTP stream through the bridge into the UI, so the preview panel comes up reliably in live mode, so the practical outcome is that the user can now monitor the scene visually while watching map pose and sensors.
The next step is letting the user work with two bots: choose which one is “live” for teleoperation (commands, camera, and map focus should all follow that selection) and eventually run both in an autonomous frontier exploration mode. That will require a clear notion of active bot identity in application state, namespaced sensor and command topics (or multiplexed streams) per bot in the bridge, and UI affordances so it is obvious which robot you are driving and which feed you are watching. Switching bots should define what happens to in-flight commands and whether camera URLs swap cleanly or need a short loading state.
For autonomy, frontier search should become an explicit mode per bot for teleoperation versus autonomous exploration with a master enable so nothing runs unattended by accident. The existing frontier and occupancy logic can be driven from live pose and LiDAR for the selected bot, with goals or motion commands issued on the same path the user uses for manual control.
Joshua’s Status Report 04/18/2026
Full gear train housings printed and tested with our wheels and all other parts as necessary also in place. Housing adjustments also made to make space for wires and solder imperfections.
Final assembly is slated to be finished tomorrow, where proper integration testing can finally ensue!
Team Status Report for 04/18/2026
The most significant risk at the moment is that we still do not have a final housing for a robot. As we write this, we have a print in progress for a finalized housing where we’ve worked out all of the remaining issues with the previous rendition which were all related to problems with mounting the breadboard and perf board after having soldered all the necessary connections. The most concerning aspect of this is that we have not been able to test and iterate on any code related to locomotion of the robot.
Since we do not have much time until the final demo, we are attempting to reduce the time we will need to spend working on locomotion by having motor driver code and teleoperation code already written so that we will only have to debug and tune constants once we are able to assemble the housing.
No changes have been made to the block diagram. Regarding schedule changes, the full assembly of the bot has taken longer than previously thought, so all of our testing and final integration will have to take place over this last week.
Brooks’s Status Report for 04/18/2026
This week I finished the plan for all of the point-to-point soldering that needed to be done between the board mounted on the front of the robot and the board mounted on the center of the robot, as well as all of the motor and power connections from the battery. We hadn’t realized how much planning it would to connect the boards in a way that would physically work when everything was actually in the housing, so this task took longer than expected. It took about a day for me to complete all of this soldering, but when it was done I was able to confirm that all of the peripherals were properly connected and working by running our code on the ESP32S3. We still need to repeat the process for an additional bot.
I also worked with Josh to make some modifications to the physical housing that were necessary in order for the boards to sit properly in the housing post-wiring. At this point, the design of the physical housing should be completely done, and we are currently waiting for the print to finish and should have it by tomorrow morning assuming the print goes smoothly. Lastly, I modified the code for streaming camera video from a catombot so that it can now be toggled remotely via a ros topic, which Adrian has integrated into the UI. We can now enable and disable camera streaming to the UI so the operator can see exactly what the robot is seeing.
Overall, the group’s progress as a whole is a bit behind as creating the physical housing has taken much longer than expected. Therefore, I have been trying to work on tasks that don’t require the physical housing to be done, but most of the integration, motor control, and robot control has been blocked by this stage. In order to catch up, Adrian and I will meet tomorrow to pick up the finished housing ASAP to test the software we have been building (autonomous search algorithm, UWB locationing and UI display, etc) as well as completing the motor control. If the autonomous searching is giving us difficulty, then we will instead spend our time implementing direct tele-operations for controlling the robot’s movements for the purpose of the final presentation.
For the final demo, we will need to build and solder another set of components for a second robot , and will need to make sure autonomous searching is functional as well. Since I was the one to plan and solder the last robot, I will be the one to do the second one. So, assembling the second robot will be my first focus, and when done Adrian and I will be working closely together on all of the software to ensure we have a working multirobot system with autonomous searching that displays robot position and sensor data to the user.
Team Status Report 04/04/2026
Completed work:
Housings are in progress, and electrical condensing is following suit.
UWB locationing is largely completed, only identifying air tags is left, and then coming up with a calibration process for the full bot setup once completed.
UI is successfully taking the data generated by the UWB and other sensors and displaying those data points on a map. Next step is to add a Kalman filter to combine our data properly over time to refine itself.
Goal for this Week (Teleoperation Prospects):
The goal is to have a bot fully operational and teleoperated by this Wednesday! That way Brooks and Adrian can move from testing in simulation to testing in reality. Housing has good progress, and I believe it reasonable to finish by Wednesday.
For electronics, we have already tested motors and getting data over WiFi, so it is now a matter of combining those principles to become teleoperation. We also have a camera on our ESP board, so that is a new thing to get working, but should not prove too difficult.
Risks:
Most risks have been seen and mitigated for. One of the bigger ones for our system is the fact that we only have 4 bots at best, and therefore are limited in our demo. However, we decided to separate the precision localization from our search algorithm to show off how the system will perform with many more as intended.
We will in one case have most bots still acting as anchors, while one or two move, and show the level of precision you can have. Then, in the other case, we will just have them all go out and search, without caring as much about the localization with respect to the global frame (as that was already proved possible with the first part)