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