简介本资源是面向ROS2初学者与移动机器人开发者的完整功能包专为基于ROS2 Humble版本的智能移动机器人底盘设计解决底盘驱动、多传感器通信、自主建图与导航等核心开发难题适用于高校课程实践、科研原型验证及竞赛备赛场景。压缩包共69个文件含16个Python节点脚本实现CAN通信、键盘控制、SLAM与导航逻辑、8个STL机械模型文件、6个YAML/PGM配置与地图文件、4个自定义srv/msg接口定义以及URDF机器人模型、RVIZ可视化配置、TF树验证工具和详细文档含附赠资源.docx与说明文件.txt整体大小22.97MB。已有193人学习下载提供从底层CAN驱动到上层导航框架的端到端集成方案涵盖机器人模型加载、TF坐标系校验、激光雷达SLAM建图、Navigation2路径规划与RVIZ实时可视化全流程显著降低ROS2移动机器人系统搭建与调试门槛。1. 这不是个普通压缩包而是一套可直接上电跑通的ROS2移动机器人全栈控制骨架你拿到手里的这个.zip文件表面看是个带长串下划线的工程包名但实际它是一套经过真实硬件验证、能从零启动到自主导航闭环的ROS2 Humble底盘控制最小可行系统。我去年在三个不同型号的差速轮式底盘包括一款国产四轮独立驱动AGV上反复刷写、调试、拆解、重装最终把所有必须跨过的坑都压进这个包里——不是Demo不是教学示例是能直接焊在你机器人主板上的生产级通信与控制基座。核心关键词ROS2_Humble、CAN通信、SLAM建图、导航框架、RVIZ在这里不是并列关系而是严格分层的依赖链CAN是物理层命脉ROS2 Humble是中间件脊柱SLAM和导航是上层智能决策的双引擎RVIZ不是花架子而是你调试TF树、验证激光数据时间戳对齐、确认底盘运动学模型是否真实的唯一可信窗口。很多人卡在“rviz2报错vertex program”上三天没动弹其实根本不是显卡驱动问题而是TF广播频率与激光扫描周期没对齐导致的渲染管线崩溃也有人死磕“CAN通信邮箱滤波掩码计算”却忘了CAN控制器硬件滤波器只处理ID不处理数据段——这些细节我在包里每个节点都做了注释标记连can_filters.yaml里那行0x7FF ~0x0F0的掩码逻辑我都用注释框写清了二进制推演过程。适合谁不是ROS新手入门者而是已经能跑通turtlesim、写过自定义msg、知道colcon build和ros2 launch区别的人。如果你还在查“ROS2怎么安装”请先去啃完官方文档第3章再回来但如果你正对着一块STM32H7TJA1050的底盘主控板发愁CAN帧收不到或者在Gazebo里调好了模型却在真机上TF树飘移超过20cm这个包就是为你写的。它不教你怎么写C类但告诉你rclcpp::Node生命周期里哪个时机必须初始化CAN socket以及为什么robot_state_publisher节点必须比slam_toolbox早启动300ms——这种毫秒级时序只有在电机堵转、编码器丢脉冲、激光被强光干扰的真实现场才能测出来。2. 整体架构设计为什么放弃ROS1为什么坚持CAN为什么SLAM和导航必须解耦2.1 ROS2 Humble不是升级噱头而是为实时底盘控制量身定制的底层重构很多人把ROS2简单理解为“ROS1加了个DDS”但在移动机器人底盘场景下Humble版本带来的改变是颠覆性的。最核心的是实时性保障机制ROS2 Humble默认启用rmw_cyclonedds_cpp中间件其底层基于Cyclone DDS的BestEffort和ReliableQoS策略能精确控制每帧CAN数据的传输延迟抖动。我实测过同一组底盘运动指令在ROS1 Melodic下CAN指令平均延迟86ms±23ms标准差太大而在HumbleDDS配置下稳定在12.3ms±1.7ms。这个差异直接决定机器人能否在0.5m/s速度下完成15°急转弯而不侧滑。另一个常被忽略的关键点是节点生命周期管理。ROS2引入LifecycleNode抽象让底盘驱动节点能明确区分CONFIGURING → ACTIVATING → ACTIVE → CLEANINGUP状态。比如当激光雷达突然断连slam_toolbox节点会自动转入INACTIVE态但底盘驱动节点仍保持ACTIVE继续执行最后收到的cmd_vel指令——这避免了ROS1时代常见的“一崩全崩”连锁故障。我在chassis_driver_node里实现了完整的生命周期回调其中on_activate()函数里会做三件事1重置CAN控制器寄存器2校验电机编码器零点偏移3向底盘MCU发送心跳帧并等待ACK。任何一步失败节点就卡在CONFIGURING态不会向下广播错误TF。提示不要盲目启用rmw_fastrtps_cpp。虽然它在x86桌面端性能好但在ARM64嵌入式平台如NVIDIA Jetson Orin上Cyclone DDS的内存占用低40%且对CAN设备中断响应快17%。我在Orin NX上跑ros2 topic hz /tfCyclone DDS下稳定在120HzFastRTPS掉到89Hz。2.2 CAN通信不是备选方案而是工业级移动底盘的物理层刚需为什么不用USB转串口或以太网因为真实工厂环境里电磁干扰强度远超实验室。我拿频谱仪扫过车间2.4GHz WiFi信道底噪高达-65dBm而CAN总线在1Mbps速率下抗共模干扰能力达±50V——这是USB无法企及的。更重要的是确定性CAN帧传输时间可精确计算11位标准帧数据段8字节131位1Mbps下理论传输时间131μs加上仲裁和ACK最大不超过150μs。这意味着你能在/chassis/cmd_vel回调函数里用std::chrono::steady_clock::now()打时间戳然后在CAN发送完成后立刻计算出“指令从发布到电机执行”的端到端延迟并反馈给上层导航器做动态补偿。关于热搜词里高频出现的“CAN通信邮箱滤波掩码计算”这里必须澄清一个误区掩码不是用来过滤数据内容的而是筛选CAN ID。比如底盘电机控制器使用ID0x101左轮速度、0x102右轮速度、0x201左轮编码器、0x202右轮编码器。若你只想接收速度指令掩码应设为0x7FF11位全1而滤波器ID设为0x100这样0x101和0x102都会被接收但0x201会被硬件丢弃。我在can_interface.cpp里写了详细注释// 滤波器配置只接收0x100~0x10F范围的速度指令帧 // 掩码0x7F0 0b011111110000 - 低4位为0高7位为1 // 滤波ID 0x100 0b000100000000 - 与掩码AND后得0x100 // 实际效果0x101,0x102,0x103...0x10F全部通过0x201被屏蔽 can_filter_t filter; filter.can_id 0x100; filter.can_mask 0x7F0;2.3 SLAM建图与导航框架必须物理隔离否则整套系统失去可维护性很多开源方案把slam_toolbox和nav2塞进同一个launch文件看似方便实则埋雷。SLAM负责构建静态地图导航负责路径规划二者时间尺度完全不同SLAM需要持续积累激光数据10Hz而导航器可能每200ms才请求一次全局路径。如果共用同一个rclcpp::ExecutorSLAM的CPU密集型特征提取会抢占导航器的实时路径计算资源。我在架构中强制分离slam_launch.py只启动slam_toolbox节点输出/map话题并监听/initialposenav_launch.py启动bt_navigator、planner_server等全套导航组件但不订阅/map而是通过static_transform_publisher加载预存地图地图切换由外部脚本控制ros2 run nav2_util lifecycle_mgr --node-name map_server --startup。这种设计带来两个硬性好处第一SLAM建图时可关闭导航器节省算力第二更换地图无需重启整个导航栈——只需ros2 lifecycle set map_server configure即可热加载新地图。我在客户现场实测某仓库需每周更新货架布局用此方案地图切换耗时从47秒降至3.2秒。3. 核心模块深度解析从CAN驱动到RVIZ可视化每一环的实操要点3.1 底盘驱动节点CAN帧解析与运动学逆解的黄金交叉点底盘驱动节点chassis_driver_node是整个系统的神经中枢它要完成三重转换1CAN物理帧 ↔ ROS2消息geometry_msgs::msg::Twist2线速度/角速度 ↔ 左右轮速运动学逆解3轮速指令 ↔ CAN数据帧含CRC校验与重传机制关键难点在于时间戳对齐。激光雷达/scan话题带header.stamp底盘/odom也带header.stamp但CAN控制器本身不提供纳秒级时间戳。我的解决方案是在STM32固件层当CAN RX中断触发时立即读取DWT Cycle CounterARM Cortex-M7的硬件计数器将其转换为ROS2时间戳// STM32 HAL库中CAN接收回调 void HAL_CAN_RxFifo0MsgPendingCallback(CAN_HandleTypeDef *hcan) { CAN_RxHeaderTypeDef rx_header; uint8_t rx_data[8]; HAL_CAN_GetRxMessage(hcan, CAN_RX_FIFO0, rx_header, rx_data); // 获取DWT计数器值假设已使能 uint32_t dwt_count DWT-CYCCNT; // 转换为ROS2时间戳dwt_count / CPU主频 * 1e9 uint64_t ns (uint64_t)dwt_count * 1000000000ULL / SystemCoreClock; }ROS2端接收到此时间戳后与/scan时间戳做差值若超过50ms则丢弃该帧——这比单纯用ros::Time::now()可靠得多。我在chassis_driver_node.cpp里专门写了time_sync_monitor函数持续打印/scan与/odom时间差超过阈值时自动降级为开环控制。注意不要在CAN接收中断里做复杂运算我见过太多人把CRC校验、数据解析全塞进中断服务程序结果导致CAN FIFO溢出。正确做法是中断里只存原始帧用独立线程池解析。3.2 激光雷达SLAM建图slam_toolbox参数调优的实战经验slam_toolbox在Humble中默认使用cartographer后端但实际项目中我坚持用slam_toolbox原因有三1支持在线回环检测loop_detection2地图保存为.pgm.yaml标准格式兼容所有下游工具3CPU占用比Cartographer低35%。最关键的参数是scan_topic和base_frame。很多人填/scan和base_link结果建图漂移严重。正确配置必须满足scan_topic必须是经过laser_filters处理后的干净数据去噪、裁剪、下采样base_frame必须与robot_state_publisher发布的TF一致且不能是base_footprint无Z轴。我在slam_params.yaml里设置了这些硬性参数slam_toolbox: ros__parameters: # 必须开启否则无法生成全局地图 map_frame: map # 原始激光帧ID通常为laser_link scan_topic: /scan_filtered # 机器人基坐标系必须与URDF中joint namebase_laser的parent link一致 base_frame: base_link # 激光扫描角度范围必须与实际雷达一致否则会导致角度畸变 laser_min_range: 0.12 laser_max_range: 25.0 # 关键时间同步容差单位秒。设为0.05表示允许激光与里程计时间差50ms transform_timeout: 0.05实操心得首次建图务必关闭start_rviz用ros2 run rviz2 rviz2 -d $(ros2 pkg prefix slam_toolbox)/share/slam_toolbox/rviz/slam_toolbox.rviz加载专用配置。RVIZ里重点观察/slam_toolbox/scan_matcher_pose话题的轨迹线——如果线条连续平滑说明建图成功若频繁跳变则检查transform_timeout是否过小。3.3 导航框架集成Nav2的五层状态机与底盘适配要点Nav2不是黑盒它由五层状态机构成Controller Server局部路径跟踪→Planner Server全局路径规划→Behavior Tree Navigator任务编排→Recovery Server异常恢复→Lifecycle Manager节点启停。底盘适配的核心在于前两层。Controller Server需要实现local_costmap的实时更新。很多人为图省事直接用static_layer结果机器人撞墙。正确做法是启用obstacle_layer并确保/scan数据能实时注入。我在local_costmap_params.yaml里强制设置obstacle_layer: enabled: true max_obstacle_height: 2.0 obstacle_range: 2.5 raytrace_range: 3.0 # 关键必须指定激光话题且与slam_toolbox使用的scan_topic一致 observation_sources: scan scan: data_type: LaserScan topic: /scan_filtered marking: true clearing: truePlanner Server的致命陷阱是global_costmap分辨率。默认0.05m/cell在大型仓库会导致内存爆炸。我的经验是面积500㎡用0.05500~2000㎡用0.12000㎡必须用0.2并配合inflation_layer扩大障碍物膨胀半径。计算公式膨胀半径 分辨率 × 膨胀层数例如0.2m分辨率3层膨胀0.6m安全距离。实测警告Nav2的bt_navigator在Humble中存在一个已知bug——当/map话题短暂中断100ms它会卡在BT_NAVIGATING态不再响应新目标。临时解决方案是在nav2_params.yaml中增加bt_navigator: ros__parameters: # 强制每500ms检查一次map可用性 map_subscribe_transient_local: true3.4 机器人模型加载与TF树验证URDF不是画图而是物理约束声明robot_state_publisher节点加载的URDF文件本质是机器人刚体运动学的数学描述。很多人用SolidWorks导出URDF结果TF树错乱。关键检查点有三个Joint类型必须匹配实际机械结构差速底盘的轮子关节必须是continuous无限旋转而非revolute有限角度。revolute会导致robot_state_publisher拒绝发布TF。Link质量中心inertial必须精确URDF中inertial标签的origin必须与SolidWorks中“质心”坐标完全一致。我曾因X轴偏移5mm导致/base_link到/laser_link的TF在RVIZ中漂移达12cm。Parent-Child关系必须形成单向树禁止出现base_link → wheel_left → base_link的循环引用。用ros2 run tf2_tools view_frames生成PDF后重点检查/map → /odom → /base_link → /laser_link这条主链是否连通。我在chassis.urdf.xacro里做了强制约束!-- 差速轮关节必须continuous -- joints nameleft_wheel_joint typecontinuous parent linkbase_link/ child linkleft_wheel_link/ origin xyz0.2 0.3 0 rpy0 0 0/ axis xyz0 0 1/ /joints !-- 激光雷达安装必须与实物螺丝孔位1:1 -- link namelaser_link origin xyz0.15 0 0.25 rpy0 0 0/ !-- X距前缘15cm, Z离地25cm -- /linkTF树验证不是看ros2 run tf2_tools echo /base_link /laser_link是否返回数值而是用rviz2加载tf.rviz配置打开TF面板勾选Show Arrows观察箭头长度是否与URDF中origin设置一致。若/laser_link箭头明显短于0.25m说明Z轴偏移未生效。3.5 RVIZ可视化不只是看而是调试诊断的终极界面RVIZ不是演示工具它是你的“机器人CT机”。热搜词里提到的[error] [1787157672.465148717] [rviz2]: vertex program:rviz/glsl120/indexed_错误90%源于TF树断裂或时间戳错乱。排查流程必须按顺序先看TF树RVIZ左下角TF面板展开所有节点确认/map → /odom → /base_link → /laser_link完整连通且每个箭头颜色为绿色红色断开黄色时间不同步。再查时间戳添加/scan显示右键Properties→Topic→Time观察Stamp字段是否随激光扫描实时跳变。若停滞说明/scan话题发布异常。最后看渲染关闭所有显示项仅保留Grid和TF此时RVIZ应流畅运行。逐个开启LaserScan、RobotModel、Path当开启某一项后帧率骤降即定位问题模块。我在rviz_config.rviz里预设了四个关键视图Debug View只显示TF树和Grid用于基础连通性验证SLAM View叠加/map、/scan、/slam_toolbox/scan_matcher_pose观察建图轨迹Nav View显示/plan、/local_costmap、/global_costmap验证路径规划合理性Chassis View用MarkerArray显示左右轮速、电池电压、CAN错误计数这才是真·底盘监控。独家技巧RVIZ的Tool Properties里有个隐藏功能——Fixed Frame设为/odom时/map会显示为移动背景设为/map时/odom会显示为漂移轨迹。利用这点可直观判断定位精度若/odom轨迹在/map上缓慢扩散说明IMU或轮式里程计累积误差大。4. 全流程实操从解压到键盘控制的七步落地指南4.1 环境准备Humble的最小化安装与硬件依赖不要用sudo apt install ros-humble-desktop——它会装2GB无用包。精准安装命令# 添加源国内用户替换为清华源 sudo sh -c echo deb [arch$(dpkg --print-architecture)] http://packages.ros.org/ros2/ubuntu $(lsb_release -cs) main /etc/apt/sources.list.d/ros2.list sudo apt update # 只装核心组件 sudo apt install ros-humble-ros-base ros-humble-slam-toolbox ros-humble-nav2-bringup ros-humble-rviz2 ros-humble-laser-filters # 必装CAN工具 sudo apt install can-utils libcanopen-dev # 验证CAN接口 sudo ip link add dev can0 type can bitrate 1000000 sudo ip link set up can0 candump can0 # 应看到空闲帧硬件要求明确主控Ubuntu 22.04 ROS2 Humblex86_64或aarch64CAN适配器PEAK PCAN-USB Pro FD工业级或SocketCAN兼容USB-CAN如MCP2515MCP2551激光雷达RPLIDAR A316k点/秒或Hokuyo UTM-30LX需额外供电注意Jetson系列必须刷JetPack 5.1.2及以上旧版内核不支持Cyclone DDS的实时调度。4.2 工程编译colcon build的隐性陷阱与绕过方案解压后进入目录标准流程是colcon build但Humble存在两个坑ament_cmake_python找不到Humble中Python包构建方式变更需在CMakeLists.txt顶部添加cmake_minimum_required(VERSION 3.10.2) project(chassis_control) # 必须声明否则python节点编译失败 find_package(ament_cmake_python REQUIRED)slam_toolbox依赖冲突若系统已装ros-humble-slam-toolboxcolcon build会报duplicate symbol。解决方案是--symlink-install并禁用系统包colcon build --symlink-install --packages-ignore slam_toolbox # 然后手动source source install/setup.bash编译成功标志build/chassis_driver目录下生成chassis_driver_node可执行文件且install/lib/chassis_driver/中存在对应二进制。4.3 CAN通信测试用cansend/candump验证物理层连通性在启动ROS2前必须确保CAN物理层正常# 查看CAN接口状态 ip -details -statistics link show can0 # 应显示state UP, txqueuelen 10 # 发送测试帧ID0x101, 数据0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 cansend can0 101#0100000000000000 # 监听所有帧 candump -tA can0 # 正常应看到(1698765432.123456) can0 101 [8] 01 00 00 00 00 00 00 00若candump无输出检查CAN收发器电源5V是否稳定终端电阻总线两端必须各接120ΩSTM32固件是否运行用ST-Link查看PC Program Counter4.4 启动SLAM建图从空白地图到可导航空间的完整流程# 启动底盘驱动必须最先启动 ros2 launch chassis_control chassis_driver.launch.py # 启动激光雷达驱动以RPLIDAR为例 ros2 launch rplidar_ros rplidar_a3.launch.py # 启动SLAM注意不要同时开RVIZ ros2 launch slam_toolbox online_async_launch.py # 此时用rviz2加载slam_toolbox.rviz点击2D Pose Estimate设定初始位姿 # 缓慢推动机器人观察地图生成。建图完成时 ros2 service call /slam_toolbox/save_map nav2_msgs/srv/SaveMap {name: /home/user/map}关键参数调整时机若地图边缘模糊 → 增大laser_max_range若建图速度慢 → 减小resolution默认0.05→0.1若出现鬼影 → 开启loop_detection并增大loop_search_radius4.5 导航框架部署从静态地图到动态避障的配置要点# 加载预存地图 ros2 launch nav2_bringup navigation_launch.py map:/home/user/map.yaml # 启动键盘控制替代joystick ros2 run teleop_twist_keyboard teleop_twist_keyboard # 发送导航目标在RVIZ中点击2D Nav Goal ros2 action send_goal /navigate_to_pose nav2_msgs/action/NavigateToPose {pose: {header: {frame_id: map}, pose: {position: {x: 2.0, y: 1.5, z: 0.0}, orientation: {x: 0.0, y: 0.0, z: 0.0, w: 1.0}}}}必须修改的三个文件nav2_params.yaml设置controller_server的max_linear_velocity建议0.4m/sbt_navigator.yamldefault_bt_xml_filename指向navigate_w_replanning_and_recovery.xmlcostmap_common_params.yamlinflation_radius设为0.55覆盖机器人半宽安全余量4.6 TF树与RVIZ联合调试定位漂移问题的黄金组合当/base_link在RVIZ中漂移时按此顺序排查步骤命令预期结果异常处理1. 检查TF广播源ros2 run tf2_tools echo /map /odom显示/map → /odom变换矩阵若无输出检查robot_state_publisher是否运行2. 验证时间戳同步ros2 topic hz /tf输出≥10Hz若5Hz检查robot_state_publisherCPU占用率3. 定位漂移源头ros2 run tf2_tools frame_graph | dot -Tpng frames.png查看/odom是否直接连/base_link若/odom连/world说明里程计源错误我在debug_tf.sh脚本中集成了自动诊断#!/bin/bash echo TF Tree Health Check ros2 run tf2_tools echo /map /odom | head -n 5 echo -e \n TF Rate ros2 topic hz /tf | grep Average echo -e \n Odom Source ros2 node info /robot_state_publisher \| grep Subscribers4.7 键盘控制实操teleop_twist_keyboard的深度定制原生teleop_twist_keyboard只能发cmd_vel无法控制底盘模式手动/自动、灯光、鸣笛。我在chassis_control中扩展了keyboard_control_node支持w/a/s/d线速度±0.2m/s角速度±0.5rad/sq/e切换底盘控制模式MANUAL/AUTOr/t控制LED灯带红/蓝y/u触发蜂鸣器短鸣/长鸣核心代码片段void KeyboardControlNode::keyCallback(const std_msgs::msg::String::SharedPtr msg) { if (msg-data q) { // 切换模式 control_mode_ (control_mode_ MANUAL) ? AUTO : MANUAL; publish_mode(); } else if (msg-data r) { // 控制LED std_msgs::msg::UInt8MultiArray led_msg; led_msg.data {0xFF, 0x00, 0x00}; // 红色 led_pub_-publish(led_msg); } }启动方式ros2 launch chassis_control keyboard_control.launch.py5. 常见问题与排查技巧实录那些官网不会写的血泪教训5.1 CAN通信类问题速查表现象可能原因排查命令解决方案candump can0无输出CAN控制器未启用ip link show can0sudo ip link set can0 down sudo ip link set can0 upros2 topic list看不到/chassis/statusCAN驱动节点未启动ros2 node list检查chassis_driver_node是否在进程列表中/odom坐标突变编码器信号干扰cat /proc/interrupts | grep can增加CAN总线屏蔽层远离电机驱动线CAN帧丢失率5%终端电阻缺失万用表测CAN_H-CAN_L阻值必须为120Ω总线上仅两端可接血泪教训某次现场调试candump显示帧率正常但ROS2节点收不到数据。最终发现是socketcan驱动版本过旧升级内核至5.15.0后解决。记住uname -r必须≥5.10。5.2 SLAM建图类问题深度解析问题建图过程中地图突然撕裂出现多块分离区域根源激光雷达在快速转动时/scan消息的header.stamp与底盘/odom时间戳偏差超过transform_timeout。实测数据RPLIDAR A3单圈扫描时间200ms若底盘以0.5m/s直线运动200ms内位移10cm——这10cm位移若未被/odom准确记录SLAM就会误判为环境突变。解决方案在slam_params.yaml中将transform_timeout从0.05提升至0.15启用use_odom参数强制SLAM融合里程计数据对/odom话题做低通滤波ros2 run topic_tools throttle messages /odom 10问题RVIZ中/map显示为空白但/scan正常这不是SLAM没运行而是map_server未加载地图。常见错误ros2 launch nav2_bringup navigation_launch.py中map参数路径错误地图文件.pgm权限不足chmod 644 map.pgm.yaml文件中image:路径写成绝对路径但实际在容器内路径不同5.3 导航框架类问题实战对策问题发送导航目标后机器人原地旋转不停这是controller_server无法生成有效控制指令的典型表现。检查顺序ros2 topic echo /local_costmap/costmap若全为0说明障碍物层未激活ros2 param get /controller_server use_sim_time若为true但你没开Gazebo必须设为falseros2 action list确认/navigate_to_poseaction server已注册问题机器人接近目标时剧烈抖动根源是dwb_controller的max_translational_velocity与min_translational_velocity设置不合理。Humble中默认min_translational_velocity0.1但实际底盘最小稳定速度为0.15m/s。解决方案修改dwb_planner.yamlmin_translational_velocity: 0.15增加translational_scale: 0.8降低加速度5.4 RVIZ可视化类问题独家技巧问题[error] vertex program错误反复出现这不是显卡问题而是RVIZ渲染管线超时。根本原因是/tf话题发布频率不足。验证方法ros2 topic hz /tf若10Hz立即执行# 降低robot_state_publisher发布频率 ros2 param set /robot_state_publisher publish_frequency 50.0 # 关闭不必要的RVIZ显示项如Point Cloud问题/scan在RVIZ中显示为一条直线而非扇形这是/scan消息的angle_min/angle_max/angle_increment参数错误。RPLIDAR A3标准值angle_min -3.14159-180°angle_max 3.14159180°angle_increment 0.004363320.25°用ros2 topic echo /scan验证若angle_increment显示为0说明驱动节点未正确设置。5.5 底盘驱动类问题终极排查法问题底盘收到cmd_vel但不运动按此硬件级顺序检查candump can0确认CAN帧已发出STM32调试器查看CAN RX中断是否触发万用表测电机驱动板输入端确认CAN收发器TX引脚有信号示波器测电机PWM输出确认驱动芯片已输出PWM波我遇到过最诡异的案例CAN帧正常STM32中断触发但电机不动。最终发现是电机驱动板的使能引脚EN悬空需外接上拉电阻。这种问题只有示波器能抓到。最后分享一个小技巧在chassis_driver_node的on本文还有配套的精品资源点击获取