★ FEATURED ARTICLE 第一次把禾赛AT128P的网线插进工控机、屏幕上刷出百万级点云的那个下午我在可视化窗口前愣了好几秒——原来“数字世界”真的可以被一秒几十次的扫描拼出来。后面几年做自动驾驶和机器人项目AT128P基本是我工具箱里最常用的激光雷达之一。这篇文章就讲和它打交道最基础也最重要的一段流程怎么把数据可靠地录下来怎么把录下来的ROS bag包处理好让它能直接用于SLAM建图、目标检测或者后续算法开发。不管你是刚拿到设备的小白还是被数据采集折腾过的老手这份全流程笔记应该能帮你少走不少弯路。1. 项目整体设计与方案选型1.1 先搞明白AT128P的数据形态与工作特性AT128P是禾赛推出的一款128线旋转机械式激光雷达水平视场角360°垂直视场角大致从-25°到15°支持10Hz和20Hz两种扫描频率标称点频约为153.6万点/秒。也就是说在10Hz模式下每帧点云大约有15.36万个点在20Hz模式下每帧约7.68万个点。测距能力方面它在10%反射率下能测到200米左右精度在±1厘米上下所以无论是园区无人车、港口重卡还是室外测绘和机器人巡检它都挺能打。算一笔账你就有概念了如果一秒钟产生153.6万点每个点用PCL里常见的PointXYZI结构来表示XYZ各4字节浮点 强度4字节再加上内存对齐的填充实际约32字节那么一秒原始点云消息的数据量就到49MB左右如果按驱动底层传输的紧凑格式16字节一个点来算也有24.6MB一秒。这意味着录制一小时点云原始bag包至少是90GB到170GB的体量。这个数字在方案设计阶段就得想清楚否则录到一半磁盘写满前面全白费。另外AT128P是纯以太网UDP输出的设备不像某些雷达走USB或者串口。驱动会从网卡抓取UDP包解析成PointCloud2消息发布到ROS话题上。理解了这个链路你才能明白为什么网卡IP、MTU、防火墙这些东西会直接影响点云质量——它们任何一个出问题点云数据就会有各种稀奇古怪的毛病。1.2 选ROS1还是ROS2驱动、话题与bag包之间的关系很多新手上来就问用ROS1还是ROS2我的建议是如果你没有历史包袱直接用ROS2推荐Ubuntu 22.04 ROS2 Humble的组合。禾赛官方对ROS2的支持现在已经很成熟启动、录包、回放都比ROS1省心。如果你所在团队还在用ROS1 Noetic也不用慌官方也有对应的ROS1驱动通信原理完全一样只是启动方式和话题名称略有差异。这里想多说一句ROS版本和驱动话题名的关系。同一个型号的雷达不同时期、不同分支的驱动发布出来的话题名可能不一样有的是/hesai/lidar有的是/hesai/pandar有的还带points或者PointCloud2后缀。我见过太多人照着网上的教程录包命令里的topic名和实际不符录出来一个空包回放时啥也没有。所以不管用哪个版本到了现场第一件事永远是先列话题确认实际名称再谈录制。另外要注意bag包和驱动版本之间的兼容性。ROS2的bag在录制时会记录消息类型定义理论上跨版本回放问题不大但如果驱动版本差异太离谱比如从旧ROS1驱动录的bag拿到ROS2里回放消息类型对不上就会很痛苦。所以严谨一点的做法是在同一套环境里完成录制、回放、处理至少保证主要节点版本一致。2. 环境准备与硬件接线2.1 硬件清单与接线布局正式开始采集之前先把现场硬件理清楚。AT128P本体之外你最少还需要这几样东西供电雷达一般支持9到32V直流供电官方适配器和线束推荐优先用。别想着省事直接拿USB或者路由器电源去带雷达启动瞬间电流不小供电不稳最典型的症状就是启动后点云闪烁、掉线。网络一根质量可靠的千兆网线最好短一点直连工控机或者笔记本的有线网口。如果不得已要通过交换机交换机的端口也必须支持千兆最好还支持巨型帧Jumbo Frame否则后面够你折腾的。上位机一台安装了Ubuntu和ROS的电脑。建议CPU至少8核内存16GB以上硬盘用SSD且预留至少100GB空间。点云处理很吃内存16G属于及格线。时间同步设备可选如果后续要融合相机、IMU或者做多传感器标定就需要给雷达提供PTPIEEE 1588或者GPS PPS秒脉冲信号。单雷达纯点云采集可以暂时不接。接线布局有一点必须提醒雷达的网口和供电口别插反也别在通电状态下拔插网线或电源虽然现在的设备都有保护但我们实测下来热插拔偶尔会把驱动搞到需要重启雷达才能恢复。稳妥的顺序是先接好网线和供电再上电等雷达自检完成再启动ROS驱动。2.2 网络参数这样配IP、MTU与端口一次讲清AT128P默认的雷达IP一般是192.168.1.201具体以设备标贴或出厂默认参数为准。你需要把上位机的有线网卡设置成同一网段的静态IP比如192.168.1.100子网掩码255.255.255.0。这一步没什么技术含量但很容易被忽略。之前有朋友遇到的问题就是雷达IP是192.168.1.201电脑却是自动获取的192.168.137.x两个网段根本不通还以为是雷达坏了。在Ubuntu下设置静态IP可以用图形界面也可以直接改Netplan配置。以22.04为例写一个/etc/netplan/01-netcfg.yaml大概长这样network: version: 2 renderer: networkd ethernets: eth0: dhcp4: no addresses: - 192.168.1.100/24 mtu: 9000然后执行sudo netplan apply。这里把MTU直接设成了9000这是官方驱动推荐的操作。为什么必须改MTU因为AT128P把一帧点云拆成多个UDP包往外发单个包的有效载荷往往超过1500字节如果网卡MTU还是默认的1500这些包会被IP层分片驱动在重组时一旦丢分片整包就废了。表现就是点云缺胳膊少腿、出现断线、频率忽高忽低。我记得第一次在现场排查这个问题用tcpdump抓包看到满屏的fragmented IP才反应过来是MTU的锅。另外确认一下驱动配置里需要填写的端口和目标IP。AT128P一般通过MSOP端口发送点云主数据DIFOP端口发送设备信息具体数值以驱动参数文件为准。如果雷达成型模式是“单播到指定上位机”那就要把目标IP填成你上位机的IP如果默认发广播地址那只要上位机和雷达在同一个局域网就能收到。这里宁可花两分钟检查也不要玄学排查两小时。2.3 驱动安装与雷达状态确认驱动安装这部分如果你用的是ROS2 Humble推荐的做法是拉取禾赛官方驱动仓库建立工作空间后直接用colcon编译。依赖方面通常会用到pcl-ros、pcl-conversions等常见包编译前先装好避免中途报错。如果你用的是社区一键安装脚本先把ROS本体装好那就能省下很多手动编译的等待时间这部分我没有太多怨言能用就行。编译完成后启动驱动前先找一下launch文件里的参数。以常见驱动为例一个启动命令可能长这样ros2 launch hesai_lidar hesai_lidar.launch.py在launch参数文件里需要确认几个关键项雷达IP、目标IP、UDP端口、frame_id。frame_id建议统一设成lidar_link后面做坐标变换和SLAM会方便很多。启动后别急着录包先看终端日志。正常的日志会显示雷达型号、序列号、转速、温度和点频等自检信息。如果日志里啥都没有或者一直报timeout多半还是网络层没通。等驱动起来后用ros2 topic list确认一下点云话题再用ros2 topic hz /hesai/lidar看看发布频率。AT128P在10Hz配置下话题频率应该在10Hz附近波动范围很小。如果频率忽高忽低、甚至只有1Hz那基本可以断定数据链路有丢包先回头检查MTU和网络质量。3. 数据采集实操录制一份能拿去用的bag包3.1 录制前的静态检查很多人一到现场就把设备架起来、驱动跑起来就开始ros2 bag record录完才发现数据有问题。我建议录制前花三分钟做一次“静态检查”费用极低收益极高。首先检查时间戳。点云消息头里的时间戳应该和当前系统时间基本一致。如果差得离谱后面做时间同步、传感器融合都会崩。可以执行ros2 topic echo /hesai/lidar/header --once看一眼stamp字段。其次检查坐标系。rviz2里添加PointCloud2把Fixed Frame和雷达的frame_id都设成lidar_link确认能看到完整的360°环视点云而不是只有某一侧的扇形。还要检查场景。确认雷达周围有没有高反射率物体、镜面、强光源、扬尘或者大面积灌木丛。这些都会让点云出现空洞或者噪点。如果是做SLAM数据集尽量挑特征丰富但不过于杂乱的场景比如有墙、有柱子、有地面纹理的园区。最后看一眼磁盘剩余空间结合点频算清楚能录多久别录到一半因为空间不足被迫中断。3.2 rosbag与ros2 bag录制命令与话题筛选驱动运行正常后录制命令其实很简单。ROS2环境用ros2 bag record -o at128p_20250218 /hesai/lidar /tf /tf_staticROS1环境用rosbag record -O at128p_20250218.bag /hesai/lidar /tf /tf_static这里有个小细节录制时建议把/tf和/tf_static一起录进去。即使你现在觉得用不到后面加轮速计、IMU或者搞建图时没有TF就要现场补发布很麻烦。如果车上还有IMU、轮速计或者相机只要你有接入ROS也一并录上。宁可录的时候多个话题不要等到需要时发现数据缺一块。如果你非常在意磁盘空间ROS2还支持压缩录制ros2 bag record -o at128p_20250218 --compression-mode file --compression-format zstd /hesai/lidar压缩会消耗一些CPU但zstd的压缩比相当可观点云消息往往能压到原来的1/3左右。实测下来在主流CPU上录制时没有明显丢帧个人挺推荐。录制过程中不要频繁开关驱动、重启RViz也不要在同一台电脑上跑重负载的建图程序。点云话题属于高带宽数据CPU和磁盘IO只要有一个成为瓶颈掉帧就会悄悄发生。录完之后第一时间执行ros2 bag info at128p_20250218看一下总时长和消息数量确认没有异常再动设备。3.3 点云实时可视化与质量初判可视化这一步很多人直接跳过但我建议把它当作质量检查的一部分。RViz2里添加PointCloud2显示后第一眼扫一遍二次反射导致的噪点、地面是否平整、墙面是否垂直、近处物体边缘是否清晰。AT128P在强光下或者扬尘环境中的噪点比室内多这是物理特性不用慌但如果点云一坨一坨的、明显出现成片的断线那就是链路问题。一个比较实用的判断方法看雷达正下方和正上方。机械式旋转雷达的点云在雷达正下方通常有盲区但垂直视场覆盖范围之内应该连续。如果你在某个固定角度看到一条细长的空洞可能是有物体遮挡或者雷达窗口局部脏污。雷达到货后外壳镜窗上贴的保护膜要是没撕干净也会导致局部点云缺失这个我在现场遇到过不止一次。质量初判没问题后再决定要不要继续长时间录制。如果只是做算法联调录30秒到1分钟就够如果做模型训练或者长期数据集建议分场景、分时段、多次短录方便后期打标签。4. bag包处理从回放到成果数据提取4.1 bag包信息查看与切片录完的bag包第一步永远是盘点内容。ROS2用ros2 bag infoROS1用rosbag info。重点关注总时长、话题列表、每个话题的消息数量以及起止时间戳。举个例子你计划录制5分钟结果只有3分钟的消息那大概率中途丢过话题或者驱动重启过。如果bag包太长想切出一段有效数据ROS2可以用ros2 bag convert带上SQLite3的WHERE条件切片。这个语法比较绕我个人更喜欢用rosbags这个Python库来处理它可以跨ROS1/ROS2格式读取和写入bag还能按时间范围过滤操作起来非常直观。ROS1里的rosbag filter命令反而更直接rosbag filter input.bag output.bag t.to_sec() 1700000000.0filter里面支持Python表达式按时间戳、话题名、甚至消息内容过滤都可以。比如只保留点云和tfrosbag filter input.bag output.bag topic in [/hesai/lidar, /tf, /tf_static]4.2 回放、时间同步与坐标变换回放bag包ROS2里是ros2 bag playROS1是rosbag play。回放时有个细节如果下游算法要接收/clock需要加--clock参数否则不少节点的时间会乱掉。另外回放速度可以用--rate控制比如--rate 0.5放慢一倍CPU压力小很多。时间同步是点云处理里最容易被忽视的点。AT128P支持PTP也有GPS接口如果采集时没有做任何同步点云消息的时间戳来自上位机系统时间。这个没有问题只要整个系统时钟是准的。但如果要与相机、IMU做融合建议用PTP把雷达和主机时钟对齐否则点云和图像之间的时间差可能达到几十毫秒甚至更大标定出来外参也不稳定。坐标变换这块雷达数据进入ROS后默认的frame_id是lidar_link。如果你要做建图或者车体规划需要把lidar_link变换到base_link。最简单的方式是用tf2_ros的静态坐标发布器在回放前先启动一个static_transform_publisher。外参可以是安装图纸上的理论值但要求高的话还是得做标定。我之前在项目里就遇到过安装支架有轻微倾斜直接量出来的尺寸根本不够后来靠标定板重新解算外参才解决。4.3 提取点云为PCD/CSV并做滤波很多时候bag包只是中间产物最终要的是PCD文件、CSV表或者一帧帧点云图片。ROS里有个现成节点叫pointcloud_to_pcdROS1和ROS2的pcl_ros包都自带rosrun pcl_ros pointcloud_to_pcd /input:/hesai/lidar这个节点会把你指定的话题持续转成PCD文件文件名带时间戳。如果你只需要保存一帧可以用rostopic echo加重定向然后写个脚本解析。更灵活的方式是用Python直接读bagfrom rosbags.highlevel import AnyReader from rosbags.typesys import Stores, get_typestore typestore get_typestore(Stores.ROS2_HUMBLE) with AnyReader([at128p_20250218], default_typestoretypestore) as reader: connections [c for c in reader.connections if c.topic /hesai/lidar] for connection, timestamp, rawdata in reader.messages(connectionsconnections): msg reader.deserialize(rawdata, connection.msgtype) # 这里把msg的x、y、z、intensity字段取出来即可 break这个脚本适合批量导出点云为CSV或者numpy数组数据清洗也比较方便。点云预处理方面必做的通常是三步体素滤波降采样、直通滤波限定距离范围、统计滤波剔除离群点。AT128P点频高直接拿原始点云跑建图会非常慢通常先用leaf size设成0.1米或0.2米的体素滤波把点数压下来。直通滤波可以砍掉自车车身上的点以及雷达附近的支架、护栏。5. 常见问题与排查技巧实录5.1 连接、驱动与丢包的典型问题我在现场遇到过的最大一部分问题都出在“看起来连上了实际没通”这一层。下面这个表格基本覆盖了最常见的情况。现象可能原因排查与解决RViz里没有点云IP不在同一网段、话题名不对、驱动没起来先ping雷达IP再ros2 topic list确认话题名最后看驱动日志点云缺线、有大片空洞MTU过小、UDP包分片丢失网卡MTU改9000网线直连重启驱动后复查点云频率忽高忽低交换机丢包、上位机CPU/磁盘瓶颈避免经过劣质交换机录制时关闭重负载程序换SSD点云有大量直线或环状噪点高反射物体、镜面、扬尘、雷达镜窗脏污清理镜窗避开强反射场景或后期用滤波器处理驱动启动后一直timeout雷达目标IP没绑定到上位机、防火墙拦住UDP检查驱动参数里的目标IP和端口关闭ufw防火墙回放时卡顿bag包没有压缩、内存不足、回放速率过高录制时开zstd压缩回放加--rate 0.5加内存你可能会觉得ping通了就应该没事但AT128P的数据是UDP流ping只证明ICMP能通不代表UDP点云包能平稳送达。所以驱动日志里没有持续的超时提示、话题频率稳定在10Hz左右这两个信号比ping靠谱得多。5.2 数据质量与工程落地的实测经验数据采集不只是“把雷达转起来录个包”的事情工程质量往往体现在细节里。举几个我自己踩过的坑。第一不要在雷达刚上电的前20秒内录包。雷达内部有旋转电机和激光器上电后需要一段时间达到稳定转速点云才会均匀。如果录得太早前面几秒的点云会有明显的扫描线扭曲和密度不均。第二长期采集时最好把原始UDP包也单独存一份比如直接抓包成PCAP格式。好处是可以完全绕开ROS驱动版本变化带来的兼容性问题以后想换驱动、重新解析拿PCAP随时可以重放。缺点是体积更大但对需要长期做数据回放的团队来说PCAPbag双份存档是我比较推荐的方案。第三录bag包的时候别漏了/tf和/tf_static。这一点前面提过但值得再强调一次。很多建图算法和Offline工具在加载bag时会要求tf完整缺了TF算法甚至都跑不起来。到时候你再想补录只能重新架设备代价就大了。5.3 一些值得记下来的效率技巧最后分享几个能提高效率的小技巧都是实测过有用的。录制前先用脚本自动检查五个要素雷达话题频率、时间戳偏差、磁盘剩余空间、数据速率和CPU负载。五要素全部正常后再录包。我在自己的脚本里就是用ros2 topic hz和df -h的组合一分钟内就能完成检查。点云导出时批量处理用rosbags库比用RViz手动保存要稳得多。尤其是要导出几千帧点云做训练集的时候脚本化是唯一可行路径。数据处理里建议保留一份“原始数据不动、处理结果另存”的目录结构别在一个文件夹里反复覆盖否则后期找不到对应关系会非常头疼。多雷达场景下每台AT128P要分配独立的IP和UDP端口避免数据串扰。之前有个朋友两台雷达用了相同端口结果两台点云混在一起点云里出现“重影”排查了很久才发现是端口冲突。我个人在实际项目中体会最深的一点是数据采集这个环节90%的问题都出在“链路不可靠”而不是“雷达不好用”。信号链路上任何一个半吊子环节——供电、网线、交换机、MTU、防火墙、磁盘——都会让后面所有算法工作翻车。所以与其迷信昂贵的传感器不如先把网线两端、供电电压、磁盘速度这些“笨功夫”做扎实。最后再分享一个小技巧录制完bag包以后我习惯随手在文件名后缀里写上场景、天气、雷达频率和采集人比如at128p_园区_晴_10hz_zhangsan.bag。这串信息在数据集归档和后期追溯时能救你无数次。
阅读完成 · 觉得有帮助？
