Month: April 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.

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.

Teleoperation Success!

There were two issues that I ran into upon integration testing the frame housing that prevented locomotion:

1. 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.
2. 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:

teleop-spinning

teleop-extended

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.

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.

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!

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)

Mechanical:

My method of developing the housing is iterative, where I make pieces, make sure they work, then move on to the next piece that uses the previous. I have gone through three different prints now (only the third having the “motor cap” once I was confident that the motor shape was form fitting), making adjustments as needed. I have gotten a housing that successfully houses the battery, snap fits together, all of the sensors and PCB boards have mounts. The only thing left is the gear box and wheels!

Here is the third print:

Here is a view of the current Full CAD assembly view:

Electrical:

We will be using the following empty PCB boards to hold our electrical components:

(Note that annotations of wirings are not yet completed, but they will be soon using our past diagram:)

We need to have a short meeting together still to discuss adjusting pins to make housing wiring easier, but since the housing specifics are mostly done by the end if this post, it should be done by Wednesday.

Next Steps:

I want to have a full bot up and running this wednesday!