ROS-Based Autonomous Wheelchair with a Web HMI

Intelligent wheelchairs exist, but they're expensive and their interfaces assume technical know-how. We wanted something cheap to build on open-source ROS, with a user interface that works on whatever device the user already has, with no installs.

Elderly and disabled users shouldn't need a Linux terminal to drive their wheelchair. This project puts a simple web page in front of a full ROS navigation stack: click a spot on the map and the wheelchair goes there on its own, avoiding obstacles along the way.

Mapping and localization. The wheelchair's lidar scans are turned into a map with grid-based SLAM (GMapping), and the saved map is used by AMCL, a particle filter that keeps the pose estimate locked to the map.

Planning. A goal arrives and a global planner (A* or Dijkstra) draws a route over the global costmap. A local planner, the Dynamic Window Approach, follows it using the local costmap, odometry and lidar: every control cycle it samples reachable (v, ω) pairs, simulates each one forward, rejects the ones that collide, and scores the rest on heading, clearance and speed. The best pair becomes the cmd_vel command, which is why the wheelchair can swerve around a new obstacle without waiting for the global plan to change. If it gets stuck, recovery behaviours kick in (clear the costmap and rotate in place).

Costmaps. Layered grids: a static layer from the saved map, an obstacle layer from lidar, and an inflation layer that makes cost fall off with distance from obstacles, which keeps the path away from walls.

Web control. Browsers can't speak ROS, so rosbridge sits in the middle and exposes topics and services as a JSON API over a WebSocket (port 9090 by default). roslibjs handles publish and subscribe, ros2djs draws the map, and a joystick plugin publishes cmd_vel for manual teleop. Odometry and the map stream back, so the page shows live position, orientation, velocities and the wheelchair on the map. A click on the map sends a navigation goal over the same channel, and because it's plain WebSocket, any device with a browser works with no ROS install on the client.

The wheelchair was designed in Fusion 360 and converted to URDF, with two wheels and two lidar scan topics. We mapped a simulated Gazebo house, saved the map, and ran AMCL and move_base on it. The ReactJS web layer was added on top through rosbridge.

To test it, we picked one source point and three destinations (A, B and C), then repeated the runs with different destinations and obstacle positions, with and without a dynamic obstacle in the way.

With a clear route the wheelchair takes the shortest path. When an obstacle appears, the local costmap updates and the planner reroutes around it, then carries on to the goal, and that held across the repeated runs.

The logs back this up. In a recording of about 12 minutes covering a full autonomous run, the sensors and wheels publish continuously, the local costmap topics update the whole time (the planner watching for obstacles), and amcl_pose arrives in bursts because AMCL only updates once the robot has moved or turned past a threshold.

The web-controlled run was logged through odometry: the robot sits still for the first ~7 s, then drives for about 33 s, and position flattens out at the goal around 40 s, with no jumps in the pose. So the run commanded from the web page was as clean as a direct one.

• A more adaptable planner, plus RFID-assisted doorway passing for better indoor precision.
• Cameras and vision models (YOLO, SSD, Fast-RCNN) for scene awareness, and sensor fusion for accuracy.
• Machine learning / deep learning to speed up real-time responses.
• Porting to a real wheelchair. Nothing here is specific to wheelchairs, so it should carry over to any indoor mobile robot.