Team E6: CatomBots

This week, I was able to complete the IMU and UWB integrations with the UI by publishing the corresponding ROS topics (/catombot/imu/heading_rad and /catombot/position) to the UI’s live ROS bridge with the micro-ROS agent docker container running. This closes the loop from multi-anchor ranging to something an operator can interpret in real time, which was the main integration milestone.

The remaining issue is the quality of the pose, not whether it appears on the screen. Raw UWB fixes are noisy as the bot’s positions appear jittery on the UI, so the next steps would be to have sensor fusion properly implemented. For UWB + IMU fusion, the IMU will be used for acceleration, which is integrated into position while letting UWB correct drift and anchor the global position. This can be done with a Kalman filter that can sooth UWB updates and uses IMU between fixes so the displayed pose and mapping see less high-frequency noise. 

UI displays the x, y, z coordinates of the bot/UWB’s location with respect to the 3 UWB anchors surrounding it.

The UI records and properly updates the bot’s position based on the latest coordinate recorded by the UWB. It does, however, vibrate despite the UWB being stationary. Hence, sensor fusion with Kalman filtering is needed.

The primary focus this week was bridging the gap between hardware-level sensor data and the live UI by getting real-time data to at least show up there rather than just the terminal/Arduino output. This involved stabilizing the ESP32-S3 firmware for distance sensing and implementing a robust micro-ROS middleware layer using Docker to ensure the frontend can reliably consume live LiDAR feeds without direct serial dependencies.

The metric on the bottom left represents the distance between the LiDAR and iPad, where the occupied cell is marked at around 30 cm. ESP32-S3 firmware (PlatformIO) reads a TF-Luna over I2C and publishes distance on micro-ROS (/catombot/lidar/front/distance_cm). Then the UI repo documents a live LiDAR bridge: micro-ROS agent in Docker, optional npm run bridge:lidar with ROS topic echo → Server-Sent Events, or --source=serial using PlatformIO serial monitor parsing. The UI can be opened in live mode (?lidar=live and related env vars).

A small read_serial.py script also helps validate raw serial timing and baud settings on macOS/Linux.

Additionally, micro-ROS Docker container was especially valuable because it turned a difficult hardware-to-browser integration problem into a much more manageable interface problem. Instead of trying to make the frontend understand ROS-native or serial-native behavior directly, the container provided a stable middleware layer that could ingest the live sensor feed, preserve useful metadata, and expose it in a form the UI could actually consume reliably.

The next steps are to calibrate LiDAR so ranges and geometry match the real map scale and robot frame, and to fuse IMU data into pose and speed estimates so on-screen motion reflects how the CatomBot actually moves. Depending on progress with UWB range triangulation, I will also surface that data in the UI (e.g. anchors and fused position) and use it to tighten FREE vs OCCUPIED classification and stabilize frontier cluster centroids that guide exploration

My plan this week was to wire Vector Field Histogram (VFH) into the live navigation loop and make frontier-based exploration visible on the tactical map so the operator can see both where coverage is growing and where the swarm is pushing next.

Across the four images, exploration grows from a small green pocket with a partial red wall outline to a fully mapped space whose OCCUPIED boundary cells form a complete red perimeter where LiDAR marks FREE interior and stamps OCCUPIED where rays hit the map edge. Teal trails stay in free space and skirt those red cells because VFH turns the global heading toward each frontier centroid into a locally safe steering angle via a polar obstacle histogram, then kinematics plus grid collision keep bots out of walls. The heatmap blooms track visit density and pile up at the leading edge of the dark UNKNOWN region, matching frontier detection (FREE cells next to UNKNOWN cells); as the frontier collapses, the map fills with green and the bright coverage fades, showing frontier-following exploration with obstacle-aware motion end to end. Once the entire map is covered with labeled/colored cells, the bots return to the base station without hitting OCCUPIED cells along the way.

VFH is implemented in src/exploration/vfh.ts, which builds a 72-sector polar obstacle-density histogram from nearby OCCUPIED cells, thresholds sectors into a blocked mask, finds contiguous free “valleys,” and picks a steering heading that stays aligned with the global goal while avoiding obstacles. The simulator (mockDataSimulator.ts) now uses this on every step: for each bot, it computes the heading toward the assigned frontier centroid, runs computeVfhHeading, then projects a short virtual waypoint along vfh.steeringHeading so the existing proportional kinematics controller tracks a VFH-safe direction. Map polygon bounds and grid-based collision resolution still apply after the move, so local avoidance and global feasibility stay consistent. Unit tests in vfh.test.ts cover histogram construction, valley finding, and end-to-end computeVfhHeading behavior.

Note that currently, the full histogram is not drawn as a separate UI panel; it powers motion in the sim. Exposing a small polar plot or debug overlay would be optional follow-on work.

Frontier logic is unchanged in principle, but the store now carries explorationGrid and frontierClusters each tick, and MapCanvas.tsx layers them so the algorithm is visible:

Status & next steps
Integration is on track: VFH is in the control loop, frontiers are fed from the same grid the sim uses, and the map reflects both. Next: optional debug visualization for the live histogram, tighter tests between VFH + multi-bot assignment under clutter, and (if needed) performance tuning of sector count / active radius for the target update rate.