简介：基于ROS2的智能轮椅自主导航系统完整工程包，适用于机器人方向的毕业设计、课程设计或期末大作业，也适合希望掌握ROS2导航仿真技术的初学者。项目以模块化方式整合传感器、执行器与导航算法，覆盖环境建模、路径规划、自主避障的完整流程。压缩包共42个文件，约1.34MB，包含launch启动脚本、yaml参数配置、urdf机器人模型、world仿真环境、rviz可视化配置等，另附stl与dae格式的3D网格模型以及png、gif演示图，便于直接运行和二次开发。资源中还包含持续集成配置和README说明，可帮助快速搭建运行环境。已有80人学习下载，适合作为参考模板理解AMCL定位、move_base全局与局部规划等核心机制，并可直接用于仿真实战或功能扩展。

1. 为什么轮椅导航比AGV难：这个项目包解决的是什么问题

智能轮椅的自主导航，本质上是一个ROS2的移动机器人导航系统，但比AGV难得多——因为人坐在上面，安全边界和速度边界完全不同。“基于ROS2的智能轮椅自主导航系统.zip”这类项目包，一般是一个完整的ROS2工作空间源码包，包含底盘驱动、激光雷达驱动、SLAM建图、NAV2导航配置、launch文件、地图文件和仿真环境。它解决的核心问题是：让轮椅在室内环境中自己规划路径、避开障碍物、稳稳停在目标点。适合三类人看：正在做ROS2课设或毕业设计的学生、想把移动底盘做成助老产品的嵌入式工程师、以及想从ROS1迁移到ROS2的导航开发者。

这个方案能不能真正跑起来，取决于几个关键点：底盘odom和tf是否正确、激光雷达话题是否对齐、代价地图参数是否匹配轮椅的物理尺寸。下面我按自己的落地顺序，把一个完整的轮椅导航系统从选型到调参讲清楚。

2. 系统架构与选型：ROS2 Humble、差速底盘和激光雷达怎么组合

2.1 底盘模型：差速轮式移动机器人的odom坐标系怎么立起来

智能轮椅最常见的运动模型是差速驱动——左右两个驱动轮，前面一个万向轮。这样的底盘在ROS2里的表达是三件事：odom话题、tf变换和cmd_vel订阅。NAV2导航时，nav2_controller输出的是速度指令，底盘节点收到后转发给电机驱动器；底盘通过轮式里程计计算位姿变化，发布odom并以odom -> base_footprint的tf广播。

这里最常见的翻车情况是：里程计坐标系和雷达坐标系没对齐，导航界面上地图在动，但机器人不在动。原因往往是base_link和base_footprint混用，或者雷达安装位置没有写在urdf里。轮椅的结构比较简单，我的做法是用urdf把base_footprint -> base_link -> laser三层固定摆放写清楚，并且一定要有base_footprint，NAV2要求它在tf树里的位置是最高层。

建图前先检查tf树，用ros2 run tf2_tools view_frames生成tf树图，看map -> odom -> base_footprint -> base_link -> laser这条链是否完整。这一步卡住的话，后面建图导航全是乱跑。参考ros2菜鸟教程里最常见的排错路径，凡是“地图翻转”“定位漂移”这类怪问题，十条里有九条是tf没搭对。

2.2 感知方案：激光雷达为主、碰撞传感器兜底

轮椅导航的感知方案和普通AGV不太一样。AGV在固定路线跑，磁条或二维码就够了；轮椅要应付的是随时出现的行人、推车、轮椅自己转向时甩出去的小腿——所以感知方案不能只靠单一的超声或红外，激光雷达是主流选择。

常见做法是：一颗2D激光雷达（比如RPLIDAR A1/A2级别）做360度或270度的障碍物扫描，配合超声或红外传感器做近距离兜底。2D激光雷达装在轮椅前方，高度在20厘米左右，覆盖轮子附近和略高于轮子的区域。安装高度如果太高，椅子扶手以下的小障碍物（比如地面上的电线、门槛）完全扫不到；安装太低，又容易把地面噪点圈进代价地图。

超声传感器一般装在轮椅前方保险杠和后方，一组两到四个，间隔10厘米左右，检测距离30到50厘米，专门覆盖激光雷达的盲区。在NAV2里可以用range传感器插件把超声数据融进local_costmap，作为obstacle_layer的额外观察源。但要注意超声的噪点比激光多得多，近距离抖动的数据会让costmap的边缘变成“毛边”，所以必须在参数里打开滤波，把超过1米的数据直接丢弃，只保留最近30厘米这一段作为紧急刹车依据。

2.3 导航栈选型：NAV2是ROS2唯一靠谱的完整导航方案

ROS2下的导航方案现实上只有NAV2是完整工业级的。MoveIt管的是机械臂，不适合轮式底盘；早年的navigation（ROS1版）没有直接迁移到ROS2；ROS2第三方导航方案也有，但生态、文档、参数调优工具链都远不如NAV2。做轮椅导航，直接选NAV2加SLAM Toolbox的组合，是当前最靠谱的路。

NAV2是一个组件化导航栈，核心模块的分工如下：

这套结构和ROS1时代的navigation差别不小，尤其行为树是新东西——bt_navigator允许你配置一套“走到目标点”的流程，卡住时先旋转、再清理代价地图、再重新规划。轮椅场景里恢复行为要谨慎：原地360度旋转会把乘客转晕，所以我把recovery_behavior_rotate的旋转角度上限限制在90度以内，配合simulate_ahead_time调小到1.0秒，让旋转试探更保守。

在选NAV2版本时我一般直接选与ROS2发行版配套的版本。Ubuntu 22.04配Humble，NAV2版本是1.2.x，它配套的SLAM Toolbox和Cartographer都维护得比较稳定。用源码编译的版本差异对轮椅这种应用来说感知不强，反而官方二进制包里经过测试的参数模板更有价值。

3. 从zip到跑起来：建图、定位与路径规划的完整落地步骤

3.1 创建功能包与底盘驱动：把odom和tf的坑先堵上

假设你拿到的是一个包含完整工作空间的zip包，第一步不是急着跑launch，而是检查工作空间结构和依赖。解压后先确认src下有哪些功能包，再挨个编译。用命令行做一次全量编译：

cd ~/wheelchair_ws rosdep install --from-paths src --ignore-src -r -y colcon build --symlink-install source install/setup.bash

rosdep解决的是系统依赖，特别是navigation2、slam_toolbox、joint-state-publisher这些包，它们在编译期和运行期缺一不可。--symlink-install参数很重要，它让launch文件和python脚本以软链方式安装，改代码不用每次重新build。如果编译过程中出现ament_cmake找不到包的情况，先检查是否把/opt/ros/humble/setup.bash加到了~/.bashrc，这是ros2入门最常见的环境问题。

底盘驱动节点是导航系统的地基。轮椅上装的电机驱动器型号很多，但从ROS2的角度看，驱动节点只需要做两件事：把接收到的cmd_vel转成左右轮速度发给电机驱动器，把电机编码器数据换算成位姿发布odom并广播tf。一个最小的底盘驱动节点看起来像这样：

import rclpy from rclpy.node import Node from nav_msgs.msg import Odometry from geometry_msgs.msg import Twist, TransformStamped from tf2_ros import TransformBroadcaster from math import sin, cos class WheelchairDriver(Node): def __init__(self): super().__init__('wheelchair_driver') # 订阅速度指令，来源是NAV2的controller_server self.create_subscription(Twist, 'cmd_vel', self.cmd_callback, 10) # 发布里程计 self.odom_pub = self.create_publisher(Odometry, 'odom', 10) # 广播odom到base_footprint的tf变换 self.tf_broadcaster = TransformBroadcaster(self) self.x = self.y = self.yaw = 0.0 # 固定时间步长做位姿推算，轮距0.6m，轮半径0.15m self.wheel_base = 0.6 self.wheel_radius = 0.15 self.vx = 0.0 self.vth = 0.0 self.timer = self.create_timer(0.05, self.tick_odom) def cmd_callback(self, msg): # 真实的轮椅底盘电机控制在这里 self.vx = msg.linear.x self.vth = msg.angular.z def tick_odom(self): dt = 0.05 self.yaw += self.vth * dt self.x += self.vx * cos(self.yaw) * dt self.y += self.vx * sin(self.yaw) * dt # 发布odom消息（含协方差，先全置零） odom = Odometry() odom.header.stamp = self.get_clock().now().to_msg() odom.header.frame_id = 'odom' odom.child_frame_id = 'base_footprint' odom.pose.pose.position.x = self.x odom.pose.pose.position.y = self.y odom.twist.twist.linear.x = self.vx odom.twist.twist.angular.z = self.vth self.odom_pub.publish(odom)

参数说明：发布频率20Hz对室内轮椅足够，轮式里程计推算精度不高，但短时间、低速移动场景下NAV2是可以接受的。如果底盘带IMU，不要急着把IMU融进tf，先把纯轮式里程计跑稳再考虑融合。如果你拿到的是C++功能包（ament_cmake写的），流程等价：用ros2 pkg create wheelchair_driver --build-type ament_cmake创建包，然后改CMakeLists.txt和src/*.cpp。C++节点发布odom的开销更低，但python写驱动更容易调试。

3.2 用SLAM Toolbox建图：轮椅通道需要什么样的地图

导航用的地图不是越精细越好，很多做轮椅导航的团队第一步就栽在地图“太花”上。SLAM Toolbox建图时，栅格分辨率的常用值是5cm，分辨率设到2cm会让地图文件体积翻倍、amcl定位抖动增加，但对轮椅导航的可用性几乎没帮助。轮椅通道关心的是门框宽度、桌子腿、墙面凸起这些离散特征，5cm的栅格已经完全够用。

启动建图分两件事：启动SLAM Toolbox和激光雷达驱动，然后用手柄或键盘遥控轮椅遍历空间。建图launch文件的常见写法：

ros2 launch wheelchair_nav mapping.launch.py

这里mapping.launch.py里至少包含：slam_toolbox节点、rviz2、激光雷达驱动和底盘驱动。建图过程中靠rviz2看实时栅格演化，地图闭合后再用map_saver保存：

ros2 run nav2_map_server map_saver_cli -f ~/wheelchair_ws/maps/room1

关键在遍历路径：沿墙走、绕一圈回到起点附近完成闭环、每个门口都要正反面走一遍。SLAM Toolbox处理回环的能力不错，但轮椅速度慢，建图耗时长，如果中途电池低压导致电机抖动，地图上会留下大量残影。我一般在建图前先检查激光雷达话题的坐标系帧名是否与urdf一致，常见错误是雷达帧写成了laser而驱动发布的是laser_link，这会导致建图时地图整体偏转。

3.3 启动NAV2导航：三步验证系统能不能自主移动

地图搞定后，导航启动就是把建图节点换成amcl和nav2_bringup。我习惯用NAV2自带的bringuplaunch文件做基底，自定义的部分写到自己的launch里：

ros2 launch wheelchair_nav navigation.launch.py map:=room1_map.yaml

启动完成后别急着点目标点，先用三个步骤做最小验证。第一步，检查rviz2里的机器人模型是否出现在地图上的正确位置；第二步，看/amcl_pose话题是否在持续更新，这一步验证定位是否收敛；第三步，手动给一个距离1米的目标点，看全局路径是否生成、机器人是否平滑起步。用户在rviz2里点2D Nav Goal，实际上是通过ROS2 action把NavigateToPose目标发给bt_navigator。action是异步的，导航过程可以取消目标、反馈进度，比服务更灵活。如果轮椅中途需要急停，调用/navigate_to_pose/_action/cancel，比直接停话题更干净。

如果机器人不走，最优先查/cmd_vel话题是否由controller_server发布出来。很多人卡在“路径画了但轮子不动”的情况，往往是控制器的odom_topic参数写错了，导致控制回路拿不到odom反馈。这里注意：NAV2里的odom_topic只认nav_msgs/Odometry类型的话题名，不是tf的odom。查话题用：

ros2 topic echo /odom -f

如果看到位姿在动，但底盘不动，就换这个命令：

ros2 topic info /cmd_vel

对比cmd_vel的消息频率和消息内容，就能判断是“导航栈没发指令”还是“底盘节点没执行指令”。这两种情况的排查方向完全不同。

3.4 先仿真后实车：Gazebo里面省下来的成本

实车调试轮椅的成本高、风险大，我强烈建议先在Gazebo仿真里把整个导航链路跑通。ROS2 Humble配Gazebo的经典组合是gazebo_ros_pkgs，用spawn_entity把轮椅urdf放进仿真世界。在Gazebo里能验证的是：tf树是否完整、odom推算是否稳定、NAV2能不能在仿真地图上导航。不能验证的是：真实电机响应的延迟、地面打滑、激光雷达在不同光照下的噪点。

有减速电机和电机驱动板的读者，可以直接把建图和导航launch搬到实车上。第一次实车建议用遥控器作为优先输入方式，同时在导航launch里加一个安全监控节点，检测到cmd_vel超过5秒没更新就主动刹车。这条安全逻辑对轮椅格外重要——在实验室跌跌撞撞只是丢脸，在人坐上去之后可能是受伤事故。类似的项目实例里，这块“安全监控节点”往往是最后才补上的，但恰恰是它决定了系统能不能离开实验室。

4. 避坑：轮椅导航最常见的5个翻车点，现象、原因和解决

4.1 现象：地图建完导入后，定位正常但导航路径严重偏移

这是整个导航系统里最玄学的现象之一。现象是amcl显示机器人在地图上的位置和实际位置偏差不大，但全局路径从起点画出了一条完全不合理的长线。

原因多数是地图坐标系和odom坐标系的yaw初始偏差过大。amcl启动时如果没有收到初始位姿或初始位姿给得不准，定位会收敛到一个“局部正确但全局错误”的位置。轮椅场景尤其容易触发，因为轮椅在地图上看起来不大的空间里，激光扫描到的墙面特征相似，粒子滤波很容易跳到错误房间。

解决：启动导航后，第一次运行务必用rviz2里的2D Pose Estimate手动给一个精确初始位姿，然后在原地缓慢转一圈让amcl收敛。收敛后检查/particle_cloud的可视化粒子是否集中在真实位附近。后续运行可以尝试用amcl的initial_pose参数给定，但第一次实车或换场地时永远不要跳过手动初始化。

4.2 现象：机器人到达目标点后反复来回抽搐，不停止

现象是路径已经规划完成，机器人也在目标点附近，但车体在±20厘米范围内一直前后左右跳动。这一条在轮椅导航中极常见，因为轮椅的转动惯量比小车大，底盘响应慢一拍，控制器就容易在目标点附近震荡。

原因有两层。第一层是局部代价地图的成本膨胀半径过大，目标点周边障碍物被视为不可通过，planner不停寻找替代路径。第二层是controller_server的路径跟踪算法在接近目标点时速度降不下来，导致过冲。

解决：把局部代价地图的obstacle_range从默认的3.0米改为1.0米，inflate_radius从0.55米降到0.3米（轮椅宽度0.6米时记住留出膨胀空间，但不要挡住通道）。同时把controller_server里min_vel_x从0.1调到0.02，这样接近目标点时允许极低的最小速度，不容易振荡。调完参数后重启navigation launch，再试就会平滑很多。

4.3 现象：导航过程中轮椅撞上了障碍物的边缘

这是最可怕的一种翻车：路径规划明明避开了障碍物，但实车却蹭到了障碍物边角。检查代价地图后发现，障碍物在rviz2里显示为正常障碍物，但导航不把它视为碰撞威胁。

原因大概率是激光雷达安装高度与全局/局部代价地图的robot_radius不匹配。如果激光雷达装在20cm高度扫描，而轮椅的扶手、脚踏板在30cm以上的宽度更大，那么激光只扫到了“下半身”，上半身在costmap中是透明的。轮椅本身就是不规则的凸包，脚踏板、扶手各部分的宽度不一致，用一个圆形robot_radius表达是不现实的。

解决：在costmap_common.yaml里配置多边形footprint，把脚踏板和扶手外沿都框进去。激光雷达只负责障碍物检测，机器人的物理边界要由footprint负责。这一步是轮椅和AGV最大的区别之一，别偷懒。

提示：footprint和inflation_radius是成对调的，只调其中一个，另一个就会成为瓶颈。

4.4 现象：建图时地图上的墙被“推开”了一到两厘米

建图时用遥控器推着轮椅走，地图上的墙面有的地方厚、有的地方薄，门框附近明显弯曲。很多人在建图阶段会忽略这个问题，等到导航阶段才发现局部路径规划绕着“不存在的凸起”走。

原因一般是轮椅转弯时里程计打滑。差速底盘的万向轮在转向时没有编码器，转向半径估算完全依赖左右轮转速，轮子打滑会让odom产生几厘米误差，SLAM Toolbox把误差“分给”地图，墙就被推歪了。

解决：建图遥控时把cmd_vel的linear.x上限临时限制在0.3m/s，angular.z限制在0.5rad/s。同时在底盘驱动节点里把里程计发布频率降到10Hz，并在odom计算前做一次轮速低通滤波。这个临时限速只影响建图阶段，不影响导航阶段速度。如果地图还是歪，考虑换Cartographer做建图，它的scan-to-map匹配对打滑更稳，代价是配置复杂一些。

4.5 现象：/map的话题正常，但rviz2里就是不显示地图

现象比较初级但很常见：map_server已经启动，话题列表里能查到/map，rviz2的Map显示组里选了正确话题，但画面上空白一片。

原因通常是rviz2的Fixed Frame没有设置成map。rviz2默认Fixed Frame是base_link，在没有tf树或tf树不完整时，地图的显示坐标是相对机体的，视觉上可以直接被“甩出屏幕”。轮椅导航的tf树至少需要map -> odom -> base_footprint这条链路存在，才可能在Fixed Frame为map时正确显示。

解决：rviz2里把Global Options的Fixed Frame设为map，然后检查tf树是否真的完整可用：

ros2 run tf2_tools view_frames

生成frames.pdf查看。凡是看到base_footprint不在树上、map -> odom有跳变，先修tf再继续。这个排查顺序适用于整篇所有话题显示异常的情况。

5. 参数调整：代价地图、规划器和速度限制的量化建议

5.1 局部代价地图的三个必调参数

NAV2代价地图参数写在costmap_common.yaml里，被全局和局部两个costmap共享。对轮椅来说，无论如何先调这三个参数。

footprint决定机器人在costmap里占多大面积。前面说过，用多边形比圆形更准。一个典型轮椅的footprint是：

footprint: [[-0.55, -0.30], [-0.55, 0.30], [0.55, 0.30], [0.55, -0.30]]

这个多边形代表一个1.1米长、0.6米宽的矩形框。注意：不要用robot_radius加inflation的方式代替，因为当轮椅靠墙时，圆形footprint会让轮的边缘和墙之间的空隙为负，影响通过性判断。

obstacle_range控制costmap“看见”多远的障碍物。设为1.0米对轮椅足够，因为navigation吞吐量不依赖这个参数，设大了反而会引进动态噪点。raytrace_range保留默认2.0米即可，它影响的是costmap中被激光穿过的区域的处理。

inflation_radius是最影响轮椅体验的参数。AGV常用的0.55米会让轮椅在门口或者两栋墙壁间距只有0.8米的通道里卡住。轮椅通常在狭窄室内环境走，通道宽度一般是0.8到1.2米，我实测inflation_radius在0.3米以下是能顺畅穿行的。但这个参数不能无限缩小，因为代价地图膨胀的作用是留出安全余量，小于0.2米时基本没有避障意义了。两个值之间，按实际通道宽度调整即可。

5.2 规划器差异：Dijkstra、A*与TCB/DWB怎么选

NAV2支持多种全局规划器和局部规划器，两个维度都要选。

全局规划器常见的是NavFn（Dijkstra或A*）。对于轮椅这种低速、小地图的场景，A*足够，Dijkstra在20米×20米地图上的规划时间差异微乎其微。但是全局路径要避免穿障碍物边角，NavFn里有一个参数allow_unknown如果设为true，会让机器人在未知区域穿行，轮椅场景必须设为false，因为室内轮椅路径在地图上应该完全已知。

局部规划器上，TCB（Timed Elastic Band）比DWB在轮椅场景更合适，因为TCB生成的是带时间参数的轨迹，对速度连续性有约束。DWB更依赖代价地图的实时性，轮椅底盘响应慢，DWB容易在狭窄区域来回打转。TCB需要调三个参数：max_vel_x、max_vel_theta、min_turning_radius。典型轮椅数值是：

controller_server: ros__parameters: max_vel_x: 0.8 max_vel_theta: 1.0 min_turning_radius: 0.3

转弯半径这个参数尤其影响轮椅——轮椅差速底盘可以原地转，但不代表应该原地转，给一个最小转弯半径反而让TCB规划出的轨迹更平滑。

5.3 速度限制：轮椅上的安全边界

轮椅是载人设备，速度限制不是可调可不调的“锦上添花”，而是安全边界。我见过的轮椅导航项目，速度上限普遍在0.6到0.8m/s之间，加速度在0.3到0.5m/s²之间。这个组合的意思是：轮椅从静止加速到最大速度需要大约2秒，从最大速度刹停的时间和距离都远小于普通小车。

对应到NAV2的controller_server参数：

max_vel_x: 0.8 max_vel_theta: 1.0 acc_lim_x: 0.5 acc_lim_theta: 1.0

为什么加速度限制比速度限制更关键？因为导航算法规划路径时如果不考虑加速度，到弯道前输出的速度和直道相同，轮椅的实际轨迹就会“甩出去”。TCB有内部的时间弹性带，但在参数里给acc_lim_x设一个合理的加速度上限，决策层就会提前减速。另外，如果轮椅坐的是老人或行动不便者，建议把max_vel_x降到0.5m/s。这个数值不是从导航算法角度定的，是从“乘坐者舒适度”定的。

速度限制的具体实现位置，NAV2的controller_server在速度指令输给底盘之前会做一次限速：min_vel_x、max_vel_x、min_vel_theta、max_vel_theta四个值控制了最终输出范围，比在底盘驱动里二次限速更早、更安全。底盘驱动里也不要完全放弃二次限速，两层限速的好处是，即使导航层配置出错，底盘也会拒绝超过安全线的速度指令。

6. 用bag回放把系统调到稳定：回归测试与指标验证

导航系统从“能跑”到“稳定”，中间隔着一个回归测试的问题。轮椅导航的参数很多，改一个inflation_radius可能让路径规划在某个角落出现新问题。在实车上每次改参数都重新跑场景，成本高到不现实。我的做法是把一次成功的实车运行录成bag，之后每次改动参数都用bag回放做回归：

ros2 bag record /scan /odom /cmd_vel /map /amcl_pose -o nav_run1 ros2 bag play nav_run1

录bag时不需要录完所有话题，只录导航决策链的核心话题：激光数据、里程计、速度指令、地图、amcl位姿。ros2 bag record生成的目录里是metadata.yaml加若干.db3文件，这是rosbag2的默认存储格式。回放时启动NAV2但不启动实车底盘，用ros2 bag play把历史数据喂进去，观察规划器是否复现同样轨迹。

回放验证有两个指标需要看。第一是/cmd_vel话题的输出是否平滑：把它录下来画图，看速度曲线有没有尖刺和阶跃；有阶跃说明controller_server在极限条件下输出了跳变速度，对应到实车上就是“顿挫感”。第二是/amcl_pose话题的协方差是否收敛：轮椅导航一两分钟后，协方差应该稳定在一个较小的数量级附近；如果协方差持续波动，说明定位在漂移，优先检查odom的轮径标定。

另外一个小技巧是给导航系统加一个“目标点测试集”。每次改参数后，跑一遍同样的3到5个目标点，记录每个目标点的到达时间、路径长度和平均速度。不用复杂的工具，用ros2 topic echo /amcl_pose加shell脚本就能采集。这套测试集的价值在于：它把“感觉好多了”这种主观判断，变成了可以比较的数字。我第一次做轮椅导航的时候，不信邪地把inflation_radius调到了0.45米，测试集直接告诉我90%的目标点路径长度增加了30%——数字比感觉可靠得多。

关于bag还有一个细节：录bag之前确认电脑时间同步，如果系统时间跳变，回放话题的顺序会错乱，整个回归测试白做。时间同步这件事在ros2里经常是隐性的，但它会以怪异的方式破坏一切基于时间戳的模块。

最后说一个我的个人习惯：每次实车测试前后，都先跑一遍ros2 doctor确认环境的健康状态后再动参数。“项目跑不动”很多时候不是代码问题，是环境里残留了上次会话的旧二进制。把这个问题规范化之后，我踩坑的比例至少降了一半。希望这套基于ROS2的智能轮椅自主导航系统从建图到调参的路径，能帮你少走几次类似的弯路。

本文还有配套的精品资源，点击获取