InFeeo
Language

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

×
Link preview After a few days of integration hell, our Raspberry Pi robot (Miu V2) can finally navigate a room on its own 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): 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. 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. 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. 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. 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 submitted by /u/Spinning-Complex [link] [Kommentare] reddit.com · reddit.com
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): 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. 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. 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. 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. 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 submitted by /u/Spinning-Complex [link] [Kommentare]

Comments

Log in Log in to comment.

No comments yet.