企业官网建设流程全解析

做ROS小车这件事，说难不难，说简单也真没想象中那么简单。前阵子我手头正好有一台钢制履带底盘，又搞到一块激光雷达，索性花了大半个月把它们组合在一起，从硬件接线到ROS环境，再到避障逻辑，完整走了一遍，最后小车真的能在房间里自己绕开障碍物跑来跑去。这篇文章就把整个项目的过程、踩过的坑、以及能直接跑的避障代码完整分享出来，适合刚入门ROS、想从零手搓一台能自主移动的小车的朋友。

在这套系统里，核心其实就是三件事：ROS负责把各个硬件模块串起来，激光雷达负责感知周围环境，避障算法负责根据感知结果决定小车怎么走。把这三件事理清楚，剩下的就是接线、配环境、调参数这些体力活了。

1. 项目概述与整体设计思路

1.1 为什么选履带底盘做ROS小车

市面上做ROS小车的底盘主要分轮式和履带式两种。轮式底盘（比如麦克纳姆轮、普通阿克曼转向底盘）在室内平整地面上表现不错，结构成熟、资料多，但通过性和负载能力相对有限。履带底盘就不太一样，它的转向靠左右两侧履带的差速来实现，和轮式差速从控制角度是一回事，但履带接地面积大、附着力强，能应付草地、碎石、甚至一些轻微的坡道。

选择履带底盘还有一个实际考虑：如果后续想扩展成室外巡检或者灾后搜救这种场景，履带底盘的机械潜力明显更大。这一步的代价是履带车本身更重、转向摩擦阻力更大，对电机扭矩和驱动板的电流能力要求更高。

实际做下来，我的体会是：履带车调试避障逻辑时，转弯响应比轮式车稍微"肉"一点，因为履带滑移转向时地面摩擦会消耗一部分动力，所以在避障参数里转向速度不能给得太小，否则车头转不过去，会直接怼上障碍物。

1.2 激光雷达选型：2D旋转雷达还是3D固态雷达

激光雷达是这套系统里单价最高的传感器，选型直接决定后续开发方向和预算。目前ROS小车项目里常见的有两大类：

一类是2D旋转激光雷达，比如思岚RPLIDAR A1/A2/A3这类，扫描出来是一圈平面距离数据。它们的优点是价格相对友好、ROS驱动成熟、数据处理简单，非常适合做基础避障和2D SLAM建图。另一类是3D固态/混合固态雷达，比如Livox Mid-360这类，扫描出来是三维点云，能感知高度方向的障碍物，适合做更复杂的感知，但价格高不少，驱动配置和点云处理也对新手更不友好。

我画了一张表，方便按自己的预算和需求快速对比：

如果你只是想把避障代码跑通，我建议从2D雷达开始。不是说3D雷达不好，而是2D雷达的数据结构简单，一个LaserScan消息里就是一个距离数组，避障逻辑可以直接在数组上算，碰到问题好排查。等2D的流程全部跑熟了，再上3D雷达时，你已经知道整个系统的数据流和排查方法，至少不会一头雾水。

1.3 整体系统架构

这套履带车避障系统的架构并不复杂，核心是一条单向数据流：

激光雷达持续扫描周围环境，把距离数据打包成ROS标准消息（LaserScan）发布到话题 /scan 上；主控电脑上的避障节点订阅这个话题，对距离数据做分区处理，判断前方、左方、右方障碍物的远近，再根据避障策略计算出期望的线速度和角速度，发布到 /cmd_vel 话题；底盘驱动节点（或者电机驱动板收到的指令）订阅 /cmd_vel，把速度指令换算成左右电机的PWM占空比，驱动履带转动。

这个架构几乎是所有ROS移动机器人的通用骨架。你以后想加SLAM建图、路径规划、遥控手柄，本质上都是在往这条数据流里插入新的节点。比如建图，就是在雷达数据流后面再接一个slam算法节点；路径规划，就是在避障节点位置替换成 move_base 这类导航框架。

2. 硬件平台搭建与核心部件选型

2.1 底盘与动力系统：履带车的电机和驱动板

底盘我用的是一台钢制履带底盘，左右各一个直流减速电机，带霍尔编码器。编码器这个配置特别重要，虽然基础避障暂时用不到轮速反馈，但后面做里程计、做SLAM建图时，编码器是必须的，所以选底盘时不要省这个钱。

电机的额定电压一般是12V或24V，功率取决于车重和履带摩擦。我这边实测下来，12V供电时，空载电流比较小，但履带在地面原地转向时电流会明显上升，所以驱动板不能选太弱的。常见的选择有L298N、TB6612，还有大功率的BTS7960。L298N虽然经典，但压降大、发热明显，用在履带这种大电流负载上不太合适。我更推荐TB6612或者直接买一块集成好的机器人电机驱动扩展板，输出能力够，而且有现成的ROS节点可以直接通过串口或PWM控制，省去自己写底层控制的麻烦。

驱动板和主控之间的控制信号一般是PWM加方向引脚。比如左边电机两个引脚控制正反转，一个引脚给PWM调速；右边电机同理。如果你用的树莓派或者带PWM输出的主控，直接GPIO输出就行。

2.2 主控选型：树莓派、Jetson还是工控机

主控是整台车的"大脑"，选型要看你的软件栈规模。如果你的目标就是跑通避障、看看雷达数据，树莓派4B（4GB及以上内存）完全够用。ROS Noetic的master节点、雷达驱动、避障节点，加起来CPU占用不会太高。但如果你打算后续跑Cartographer、跑导航、或者接3D雷达做点云处理，树莓派就会比较吃力，这时候Jetson系列（Nano/Orin NX）或者x86工控机是更好的选择。

我自己用的是Intel NUC类的迷你工控机，原因就一个字：稳。x86架构跑Ubuntu和ROS生态最顺，USB带宽足，供电比树莓派抗造，不用担心SD卡损坏，也不用折腾交叉编译。缺点是功耗和体积比树莓派大，但只要你的底盘不是特别迷你的那种，塞一台NUC问题不大。

选型时可以记住这个原则：雷达数据量小、算法简单时，树莓派够了；数据量大、算法复杂时，优先上x86或带GPU的平台。

2.3 供电方案与电气连接

供电这块是新手最容易翻车的地方。履带底盘上有两个主要的用电单元：电机和主控（含雷达）。电机瞬间电流大，电压波动明显，如果主控和雷达直接从同一个电源取电，电机一启动就会把母线电压拉低，轻则雷达掉帧，重则主控直接重启。

正路是分路供电：一块12V锂电池单独给电机驱动板供电，另一路通过DC-DC降压模块给主控供电。如果只有一个电池，那也要在电机驱动板的电源输入端并联一个大容量的电解电容（比如470uF以上），尽量吸收电机启停瞬间的尖峰。雷达如果走USB供电，主控的USB口电流可能不够，最好用带单独供电的USB HUB，或者直接把雷达的供电线接到稳压模块上。

连接顺序也有讲究：先把雷达和主控的地线共地，再插USB数据线。两个系统如果不共地，USB通信经常会出现随机断连、数据错乱这种疑难杂症，排查起来非常头疼。

2.4 激光雷达的安装与通信方式

激光雷达的安装位置有两个硬性要求：一是要保证360度扫描视野不被车体自身遮挡，二是扫描平面要尽量水平。履带车因为有悬挂和履带张紧，车身姿态在运动时会有一点俯仰，如果雷达装得不稳，扫描平面一歪，避障判断的距离就会失真，严重的时候会漏掉低矮障碍物。

我的做法是给雷达加了一个3D打印的支架，固定在底盘前部的安装板上，雷达本体离地面大约15cm到20cm。这个高度对室内常见的椅子腿、纸箱、墙壁底部来说，基本都能扫到。

通信方式上，2D雷达一般是USB串口，插上主控后会出现 /dev/ttyUSB0 这样的设备节点；3D雷达（比如Mid-360）一般走网口，需要给雷达配一个和主控同一个网段的静态IP。不管是哪种，第一步都是确认主控能读到数据，再进ROS。

3. 软件环境准备：ROS安装与工作空间初始化

3.1 Ubuntu与ROS版本搭配

ROS版本和Ubuntu版本是绑定的。目前最稳定、教程最多的是 Ubuntu 20.04 + ROS Noetic，这也是我推荐新手使用的组合。如果你的电脑已经是Ubuntu 22.04，那对应的是ROS 2 Humble，但很多老教程和驱动包还是基于ROS 1的Noetic写的，对新手来说，先别追求版本新，能跑通更重要。

Ubuntu 24.04对应的ROS版本（比如Jazzy）还在快速更新中，一些第三方的雷达驱动包未必同步支持，所以不建议现在踩这个坑。一句话总结：桌面级ROS小车折腾环境的时间成本极高，选最主流的组合等于省下大量查错时间。

3.2 ROS安装：手动配置与自动化脚本

ROS的安装分成两部分：添加软件源和安装核心包。手动安装需要先加ROS官方源、设置密钥、更新索引，然后才能装ros-noetic-desktop-full。这个流程本身不复杂，但国内网络环境下，官方源经常慢到怀疑人生，需要换成国内镜像源，对新手来说每一步都可能卡住。

我当时在项目里为了方便，直接用社区里流传较广的ROS自动化安装脚本（网上常说的“一键安装”）。这类脚本会自动完成换源、装依赖、初始化rosdep等一系列步骤，一条命令跑完，省去大量手动配置工作。如果后续想在多台设备上装ROS，这个方式几乎是最省心的一种。

装完之后养成一个好习惯：执行 sudo apt update && sudo apt upgrade，并且手动编译一下工作空间，确认基本依赖没问题再往下走。

3.3 创建工作空间与雷达驱动包准备

ROS里的代码组织单位是工作空间（workspace），一般叫 catkin_ws。创建步骤很简单：

mkdir -p ~/catkin_ws/src cd ~/catkin_ws catkin_make

如果编译过程中报缺依赖的错误，就用rosdep install --from-paths src --ignore-src -r -y这条命令把缺失的依赖装齐。这一步极其常见，新手别慌，报错信息里一般直接写了缺哪个包。

雷达驱动这块，2D雷达厂商一般都会提供ROS驱动包，下载源码放到 src 目录下，编译后就能用。编译时注意主控的ROS版本和包的兼容性，如果报错，优先看是不是缺某个依赖没装。

4. 激光雷达驱动配置与数据可视化

4.1 雷达上线：串口权限与话题确认

雷达插上主控后，第一步是确认系统识别到了设备：

ls /dev/ttyUSB*

如果能看到设备节点，说明USB转串口芯片已经工作。但ROS驱动需要读写该串口，而默认串口设备属于 dialout 用户组，当前用户很可能没有权限，导致驱动启动时报 "permission denied"。解决办法是把当前用户加入 dialout 组：

sudo usermod -aG dialout $USER

改完需要重新登录用户才能生效。这个权限问题几乎每个玩雷达的人都会遇到一次，建议提前处理。

3D雷达如果是网口通信，还需要把雷达的IP和主控网口的IP配到同一网段。比如雷达出厂IP是192.168.1.208，那主控的网口就手动设置为192.168.1.50这种同网段的静态IP，然后在驱动launch文件里指定雷达的IP地址。

配好后启动雷达驱动，在另一个终端里用rostopic list查看话题，应该能看到 /scan 或者 /livox/lidar 这样的点云话题。再用rostopic echo /scan打印几帧数据，看到 ranges 数组里不断变化的距离值，说明雷达数据已经顺利进入ROS了。

4.2 用Rviz查看激光数据

命令行看数据不直观，把数据可视化出来才能验证雷达的扫描范围和安装角度是否正确。启动Rviz：

rosrun rviz rviz

然后在左侧的 Displays 面板里点击 Add，添加一个 LaserScan 显示插件，在话题（Topic）栏填 /scan，再修改 Fixed Frame 为激光雷达的坐标系名称（一般是 laser 或者 laser_frame）。如果设置正确，就能看到一个以雷达为中心的一圈红色点云，这就是雷达实时扫描到的环境轮廓。

看到这圈点云的那一刻，整个项目就成功一半了。因为这说明从硬件到驱动到ROS通信，整条链路全部打通：雷达有数据、驱动在发布、系统在转发、Rviz能收到。后面的避障代码，本质上就是在操作这个红圈里的数据。

4.3 理解LaserScan消息结构

在往避障代码里写数据索引之前，必须先搞清楚LaserScan消息里每个字段的含义。LaserScan消息最关键的部分是这几个字段：

• angle_min / angle_max：扫描的起始角度和结束角度，单位是弧度。2D雷达一般是 -π（-180°）到 π（180°），但不是所有雷达都覆盖完整的360°，有些角度范围只有270°，这个要看雷达手册。
• angle_increment：相邻两个扫描点之间的角度增量。
• range_min / range_max：雷达有效测量的最小和最大距离。
• ranges：一个浮点数组，存的是每个角度上测到的距离值，单位是米。

ranges 数组的下标和角度的关系是：角度 = angle_min + 下标 * angle_increment。比如某雷达angle_min是0，angle_increment是1°（换算成弧度），那么ranges[0]就是0°方向测到的距离，ranges[90]就是90°方向的距离。

理解了这个对应关系，避障代码就变得很简单：从 ranges 数组里把前方某个角度范围内的距离值取出来，取最小的那个和设定的安全距离比较，就是"有没有东西挡路"的直接依据。

5. 避障算法设计与代码实现

5.1 避障原理：把激光数据变成行驶决策

避障问题可以抽象成一句话：感知周围环境，根据障碍物的位置决定下一秒往哪走。这个决策过程不需要机器学习，不需要高深算法，用最基本的"分区判断"就能实现。

思路是把雷达扫描范围分成三个区域：左方、前方、右方。每个区域取该角度范围内最近的障碍物距离。然后按照下面的优先级做决策：

• 如果前方障碍物距离大于安全距离，说明前方没有障碍或很远，小车直行；
• 如果前方有障碍，就看看左右哪一侧更空旷，转向空旷的一侧；
• 如果左右两侧都不满足避让条件（都太近了），小车原地后退或者旋转，重新寻找可通行方向。

这里的关键是"安全距离"和"区域角度范围"这两个参数。安全距离设太大，小车离障碍物老远就停下拐弯，表现在行为上就是敏感、走不了直线；设太小，小车离障碍物太近才反应，可能会撞上。区域角度范围设宽了，侧向感知太灵敏，小车会频繁转向；设窄了，又容易漏掉侧面靠近的障碍物，发生侧面刮蹭。

我在实际测试里，室内环境下安全距离设定在0.35米到0.5米之间比较合适，前提是车速在0.15m/s左右。车速越快，安全距离就要相应加大，否则刹车距离不够。

5.2 完整避障代码：LaserScan分区决策

下面是整个项目最核心的避障节点代码，直接用rospy写，依赖非常少，只需要在ROS环境里装了rospy和sensor_msgs就能跑。这份代码我实测下来可以稳定运行，你直接复制到脚本里改成可执行文件，然后rosrun启动即可。

#!/usr/bin/env python3 import math import rospy from sensor_msgs.msg import LaserScan from geometry_msgs.msg import Twist class ObstacleAvoidance: def __init__(self): rospy.init_node('obstacle_avoidance_node') # 发布速度指令到/cmd_vel self.cmd_pub = rospy.Publisher('/cmd_vel', Twist, queue_size=1) # 订阅激光雷达数据 self.scan_sub = rospy.Subscriber('/scan', LaserScan, self.scan_callback) # 保存最近一帧雷达数据 self.latest_scan = None # 可调参数 self.safe_dist = rospy.get_param('~safe_dist', 0.4) # 安全距离（米） self.linear_speed = rospy.get_param('~linear_speed', 0.15) # 直线速度（m/s） self.turn_speed = rospy.get_param('~turn_speed', 0.35) # 转向速度（rad/s） self.rate = rospy.Rate(10) # 控制频率10Hz def scan_callback(self, msg): self.latest_scan = msg def get_region_distance(self, scan, angle_min, angle_max): """ 计算某个角度范围内的最近障碍物距离。 angle_min / angle_max 的单位是弧度，逆时针为正。 """ min_dist = float('inf') # 雷达扫描点角度范围要处理好正负跨越 for idx, r in enumerate(scan.ranges): if not math.isfinite(r): continue if r < scan.range_min or r > scan.range_max: continue angle = scan.angle_min + idx * scan.angle_increment # 处理角度范围跨越 -pi/pi 的情况 # 比如要找[-pi, -2pi/3]范围，归一化到[-pi, pi] while angle > math.pi: angle -= 2 * math.pi while angle < -math.pi: angle += 2 * math.pi if angle_min <= angle <= angle_max: if r < min_dist: min_dist = r return min_dist def decide_and_publish(self): if self.latest_scan is None: return scan = self.latest_scan # 划分三个区域：左方、前方、右方 # 以车头朝向为0度 front_region = self.get_region_distance(scan, -math.pi / 6, math.pi / 6) # -30° ~ 30° left_region = self.get_region_distance(scan, math.pi / 6, math.pi / 2) # 30° ~ 90° right_region = self.get_region_distance(scan, -math.pi / 2, -math.pi / 6) # -90° ~ -30° twist = Twist() if front_region > self.safe_dist: # 前方安全，直行 twist.linear.x = self.linear_speed twist.angular.z = 0.0 else: # 前方有障碍，比较左右两侧距离 if left_region > right_region: twist.linear.x = 0.05 twist.angular.z = self.turn_speed # 左转 elif right_region > left_region: twist.linear.x = 0.05 twist.angular.z = -self.turn_speed # 右转 else: # 左右都不满足时，原地左转找路 twist.linear.x = 0.0 twist.angular.z = self.turn_speed self.cmd_pub.publish(twist) def run(self): rospy.loginfo("obstacle avoidance node started") while not rospy.is_shutdown(): self.decide_and_publish() self.rate.sleep() if __name__ == '__main__': try: node = ObstacleAvoidance() node.run() except rospy.ROSInterruptException: pass

代码的核心在 decide_and_publish 函数里。每次从激光数据里采样三个方向的最近距离，然后按决策逻辑计算速度指令。

有几个参数我单独说明一下。

• safe_dist：前方触发避障的距离阈值。0.4米在室内已经算比较激进的设置，车速慢的话够安全。如果你想让小车更保守一点，调到0.6米。
• linear_speed：直行速度。履带车负载重、惯量大，起步建议不超过0.2m/s，不然避障来不及反应。
• turn_speed：转向角速度。履带车原地转或绕行时如果转速太低，车头转向力矩不够，会划着弧线冲向前方障碍。0.35rad/s是一个比较合适的中间值。

启动方式有两种。如果节点文件在功能包scripts目录下，先加可执行权限：

chmod +x obstacle_avoidance.py

然后：

rosrun your_package obstacle_avoidance.py

或者如果你只是验证代码逻辑，也可以直接放在任意目录，用python3 obstacle_avoidance.py启动，前提是ROS环境已经source过（source /opt/ros/noetic/setup.bash）。

5.3 参数调节与实测注意事项

代码能跑起来和跑得好，是两码事。我在调试这套避障参数时，记录了一些真实遇到的问题和处理思路。

第一个问题是角度范围的选择。激光雷达的0度朝向一般和车头方向重合，但有些雷达装在车上会有安装偏角。如果你发现小车对着正前方的障碍物没反应，但侧面很敏感，那大概率是雷达的0度方向和车头方向没对齐。解决办法是先在Rviz里对比雷达点云和车体的实际朝向，如果偏了，要么物理调整安装角度，要么在驱动launch文件里加一个frame旋转补偿，或者在代码里把分区角度整体平移一个偏置角。

第二个问题是障碍物漏检。低矮物体（比如门槛、台阶）在2D雷达扫描平面以下，雷达扫不到，导致小车正面撞上。这是2D雷达的结构性限制。如果你真的要经常跨门槛，要么把雷达安装高度降低，要么后续换3D雷达。室内平地上，这个问题基本可以忽略。

第三个问题是决策频率。我定的控制频率是10Hz，也就是每0.1秒做一次决策。频率太低（比如2Hz），小车在两次决策之间冲出去的距离就会太长；频率太高则没有必要，因为雷达扫描频率本身一般也就是10Hz左右，你决策得再快也无法获取更多新信息。10Hz是ROS小车非常常用的控制频率，兼顾了实时性和稳定性。

6. 实测效果与常见问题排查

6.1 最容易踩的五个坑

这套系统我前后调试了两周，把主要的问题整理成一张表，每个问题都对应了具体的排查方向：

表里的最后一条，PWM震动问题，是履带车特有的。履带传动链长、摩擦力大，太低的PWM占空比会让电机处于"要转不转"的边缘状态，这时候齿轮箱里就会传出明显的嗡嗡声。解决办法是给速度指令加一个死区，低于某个速度就直接给0，高于这个速度就一次性给到一个足够克服摩擦的占空比。很多成品机器人驱动板在固件里已经做了这个处理。

6.2 排查思路：从数据流倒着找问题

调试机器人有个万能的排查思路，就是从数据流的下游往上游逐级检查，永远不要一上来就怀疑算法。

先说一个我自己的真实经历：有一次小车直行时完全无视正前方的纸箱，直直撞上去了。我第一反应是避障代码有bug，翻来覆去看了好几遍决策逻辑，没发现问题。后来用rostopic echo /scan打印数据，发现雷达正前方距离值显示的是3.5米——可是明明纸箱就在半米外。最后拆开雷达外壳，发现是雷达的透光罩上沾了一大块泥巴，把正前方的激光挡住了。

所以正确的排查顺序是：

1. 先看话题数据对不对。rostopic echo /scan、rostopic hz /scan，确认雷达在发、频率正常、数据里能看到障碍物。
2. 再看速度指令对不对。rostopic echo /cmd_vel，用障碍物挡在车前，看避障节点是否发布了转向指令。
3. 最后看执行机构对不对。拔掉雷达，用手推一下小车，或者直接给/cmd_vel发一条固定速度指令，看电机是否按预期转动。

这三步走完，问题必然被定位到雷达感知、算法决策、底盘执行这三层中的某一层。绝大多数所谓"玄学故障"，最后都能这样一步步查到根因。

6.3 从避障到建图导航的扩展路径

避障跑通之后，如果你还想继续往下走，方向很清晰：建图和自主导航。这也是标题里提到"自动驾驶小车"的核心延伸。

建图推荐用Cartographer或者Gmapping，它们能把激光雷达数据拼成一幅二维地图。和避障的最大区别是，建图需要同时用到雷达数据和里程计数据（也就是左右电机编码器反馈的位移信息）。如果你的底盘只有PWM调速、没有编码器反馈，就需要先补一个里程计发布节点，把编码器脉冲数换算成位移，以odom坐标系发布出来。这一步是整个建图流程里工作量最大的部分。

有了地图和定位之后，导航就顺理成章了。move_base框架负责在地图上搜索一条从当前位置到目标点的路径，同时持续接收激光雷达数据做局部避障——我在前面写的那个分区避障算法，本质上就是move_base里局部代价地图的一个极简实现。

所以从长远看，这篇避障代码相当于给你搭好了一个最小系统骨架。日后无论是换更高性能的主控、上3D雷达、还是接语音模块、机械臂，改动都不会超出"往ROS节点图里插新节点"这个框架。

写在最后

这套履带避障车做下来，我最深的感受是：ROS小车的难点从来不在某个单一环节，而在于把"硬件-驱动-算法-执行"这条链路理顺。雷达不出数就怀疑驱动，驱动没问题就看算法，算法没错那就回头检查机械，这个排查逻辑比任何单个知识点都值钱。

如果你也想复刻这个项目，我建议别想着一次到位，先让雷达转起来，再让车轮动起来，最后再把两者合到一起。每走一步都确认一下当前阶段没问题，再进入下一步。我见过太多人上来就急着跑避障代码，结果雷达权限没配、坐标系没对上、速度参数没调，最终只能在报错日志前干瞪眼。

技术路线上，接下来你还可以给这辆小车加上远程遥控、语音控制、目标点导航，这些都是顺着这套ROS框架自然生长出来的能力。先把这篇文章里的核心代码跑通，你就已经站在一个相当不错的起点了。