Assistive Navigation Robot

The robot runs ROS 2 on a Raspberry Pi 5. I built the assistive-navigation layer (three application nodes) on top of the Yahboom platform's vendor stack (the sensor drivers, EKF localization, SLAM mapping, and the Nav2 navigation pipeline), which is what let me spend my effort on the navigation logic instead of re-solving mapping and motion control. room_navigator turns a named room into a Nav2 goal pose; red_tape_detector injects floor-hazard no-go regions into the costmap; and a furniture detector keys on room objects by colour, shape, and pattern.

Navigating tight domestic spaces is hard for wheelchair users, and the repetitive trips (kitchen, bathroom, bedroom) add up to real daily strain. I set out to prototype the software for an assistive "smart wheelchair": a system that could map a home, localize within it, detect and route around obstacles, flag floor-level danger zones, and drive a user from wherever they are to a room they name, safely, and with a check that it actually arrived.

I designed and built this end to end. I wrote the navigation system and the whole application layer on top of the robot's ROS2 stack: the room-to-room route planning, the computer-vision detectors for floor hazards and furniture, the QR-checkpoint arrival logic, and a parallel software simulation of the entire navigation loop. The workflow diagram below is mine.

I built on a standard robotics foundation. The Yahboom Raspberry Pi 5 platform ships a ready-made ROS2 stack (Nav2 navigation, SLAM mapping, the Astra depth-camera and lidar drivers, EKF sensor fusion), which is exactly what let me put my effort into the assistive-navigation logic instead of reinventing mapping and motion control.

The robot first builds a 2D map of the space with its onboard lidar, then localizes against it. On a "go to the bedroom" command, a custom ROS2 node I wrote looks up the room's recorded coordinates and hands them to Nav2 to plan the route, and when the lidar sees an obstacle within ~0.5 m of the planned path, Nav2's costmap flags it and the planner routes around it rather than stopping dead.

Two computer-vision pieces run alongside the planner. A red-tape detector segments red floor tape (a stand-in for stair edges and other hazards) using two HSV colour bands (so it survives changing light) with morphological cleanup, at 10 Hz, so the planner can treat those regions as no-go. A furniture detector combines colour, shape, and pattern cues to identify objects in a room. And at each destination, the robot scans a wall QR code carrying a 10-digit location ID to verify it reached the room it was actually headed for.

I also built the whole navigation loop as a parallel software simulation: a turtle-graphics agent with an OpenCV / pyzbar barcode reader, running the scanner and the moving agent as concurrent processes so the agent pauses at each checkpoint until the right code is read. It gave me a clean, controllable testbed for the path-planning and checkpoint logic while the physical build fought real sensor noise.

I delivered a working system on both fronts (a physical robot and the simulation) and recorded a demo of it driving the arena autonomously. In the taped-out five-room "house" I built, the robot localized, planned to named rooms, reacted to obstacles inside 0.5 m, flagged red-tape danger zones, and confirmed arrival by QR code.

The instinct I'm proudest of here is leverage: building on a capable vendor platform let me put the effort where the actual problem was (the assistive-navigation logic, the hazard detection, the arrival guarantee) instead of re-solving mapping and motion control. It pairs with my RECLAIM capstone as a second robotics build around the same closed perception → planning → actuation loop, just aimed at helping a person move through their own home.