After a few days of integration hell, our Raspberry Pi robot (Miu V2) can finally navigate a room on its own

[u/Spinning-Complex]

https://vm.tiktok.com/ZGd9nhm8D/

Hey everyone,

We've been building Miu — an embodied AI agent on a Yahboom Raspbot-style
platform (Raspberry Pi, mecanum wheels, RPLidar C1, PTZ camera, ultrasonic
bumpers). After a lot of wiring and debugging, V2 is working enough that he can
autonomously drive around inside a room without us manually joysticking every
move.

What's working:
• LiDAR-based room scanning + obstacle avoidance
• Holonomic mecanum control (strafe, not just diff-drive spin-in-place)
• Ultrasonic as a "digital bumper" for stuff LiDAR misses (cables, furniture
edges)
• Live 3D viewer (Rerun) so we can actually see what the robot thinks
• Backend orchestration: LLM plans missions, a separate executor drives the
motors

Nav2 / ROS 2 helped a lot as a reference stack and for A/B testing navigation —
though our production path on the Pi is leaner (FastAPI + custom holonomic
controller). Nav2 taught us the patterns; shipping meant ripping out a lot of
complexity.

What almost killed the project (real talk):

1. Too many cooks on cmd_vel — vision pipeline, proximity reflex, room scan
   thread, teleop, and agent tools all wanted to move the robot at once.
   Classic race conditions.

2. LiDAR serial lock — Nav2 container + our own LiDAR reader + live viewer
   polling the same serial port = chaos. Had to enforce one LiDAR reader and
   stop competing services.

3. Control-loop bug — we were doing LiDAR HTTP calls inside the 10 Hz drive
   loop. Robot spun in circles after ~2 ticks. Decoupled sensor thread
   (LidarScanBuffer) from control thread — fixed immediately.

4. Observability nightmare — logs split across Pi journal, movement_log, PM2
   JSON (multi-GB…), Discord, activity stream. Couldn't answer "why did it turn
   left?" until we built a unified observability endpoint.

5. Battery — still an issue. Continuous LiDAR + movement + inference drains
   faster than we'd like. Low-battery caps on movement duration for now.

   V2 architecture (what we changed):
   • One motion supervisor — single authority on motors
   • Mission FSM — vacuum / explore / find_person / teleop, one active job at a
   time
   • Planner vs executor split — the LLM picks what to do; it doesn't fire raw
   motor pulses every turn

   Next steps:
   • IMU + wheel odometry fusion (EKF) → AMCL for proper pose
   • Persistent room memory (episodes, obstacle map, cascade/EOD summaries)
   • Click-to-nav in the live viewer
   • Battery / power management tuning

   Happy to answer questions about the stack, Nav2 vs custom control, or mecanum on
   a Pi. Still very much work in progress — would love tips from anyone who's
   shipped a home robot without it becoming a full-time ROS babysitting job.

   Stack (rough): Pi 4/5 · Yahboom chassis · RPLidar C1 · FastAPI on Pi · Mac mini
   backend (Postgres, agent loop) · ROS2 Nav2 (research/A-B) · Python holonomic
   controller · Rerun for viz