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.