简介面向3D点云处理开发者与学习者此资源包提供bin格式与pcd格式互相转换的实用工具链。bin格式为激光雷达原始二进制点云数据紧凑但缺乏元数据pcd格式是PCL标准格式可保存坐标、颜色、法线及头信息二者互转是数据预处理与跨平台分析中的常见需求。压缩包共265个文件约4.45MB主要包含100个txt文本数据、101个json配置参数、11个sample样本、4个head头信息以及2个Python转换脚本同时附有bin、pcd示例文件和说明文档目录结构清晰便于检索。已有2123人浏览学习。资源内含bin2pcd.py转换脚本、相机配置JSON、标定文件生成脚本及多组点云样本读者可对照sample与head理解数据组织形式结合json参数掌握坐标校准流程快速将原始bin数据转为带结构信息的pcd文件应用于PCL处理、自动驾驶点云感知或机器人定位等场景。1. bin 转 pcd 为什么是个真需求一份带踩坑记录的点云格式转换资源在车上装了一圈激光雷达标定做完之后最先卡住的往往不是算法精度而是数据格式。算法节点只认 pcd采集端吐出来的却是 bin——pcap 包里拆出来的裸点云没有头部信息一个文件就是一大堆浮点数。这种 bin 格式在自动驾驶公开数据集里太常见了常见到每个接触点云的人迟早都会撞上一次。这份资源就是为这个场景准备的一套把 bin 转换成 pcd 的完整处理链覆盖单文件转换、批量转换、降采样与裁剪以及我实际踩过的几个深坑。适合已经在跟点云打交道、手头正好有一批 bin 要喂给只认 PCD 的后端节点的人也适合刚入门想搞清楚两种格式底层差异的人。2. 先摸清两种格式的脾气KITTI bin 的裸字节与 PCD 的 header 结构2.1 bin 就是没有头信息的 float 数组bin 格式最反直觉的地方就是它什么都不告诉你。一个 KITTI 风格的 .bin 文件里没有版本号、没有字段名、没有点数声明你唯一能依赖的就是「每点 4 个 float32」这个约定。这 4 个 float32 分别是 x、y、z 和反射强度前三个是空间坐标单位是米最后一个是雷达反射强度通常是 0 到 1 之间的浮点数。每个点固定占 16 字节所以一个 bin 文件的总字节数除以 16理论上就是点数。如果文件总字节数不是 16 的倍数那这个文件大概率不是标准的 KITTI 布局。可能是采集系统在每帧前面加了时间戳头也可能是损坏文件。我拿到陌生 bin 文件的第一件事永远是先看文件大小而不是直接丢进转换脚本。常见做法是把文件大小和点数记录下来作为一个基准确认。如果你发现文件尾部有额外的 4 字节或 8 字节先把它切掉再转换否则转出来的 pcd 最后会多出一个残缺点。另一个容易忽视的点是 endianness。绝大多数采集设备按小端序存 float32x86 机器上也默认小端所以直接按 float32 读一般没问题。但如果数据是从嵌入式设备拷贝出来的偶尔会碰到大端序文件特征是整个点云坐标数值巨大或者全部反转。遇到这种情况用 np.fromfile 读完后加一句raw.byteswap()再 reshape基本就能救回来。2.2 用 Python 读裸字节核对字段布局拿到 bin 文件后别急着转 pcd先做一次字段核对。读出来后打印前几个点和各维度的 min/max确认坐标量级合理。下面这段代码是纯 Python NumPy 的 sanity check不依赖 PCL适合在任何环境里跑。import numpy as np def inspect_bin(bin_path): raw np.fromfile(bin_path, dtypenp.float32) # 一次性读入所有 float32 if raw.size % 4 ! 0: raise ValueError(f{bin_path} 不是每点 4 个 float32 的布局) cloud raw.reshape(-1, 4) # 每行一个点x y z intensity xyz cloud[:, :3] intensity cloud[:, 3] print(point count:, cloud.shape[0]) print(first 5 points:\n, cloud[:5]) print(xyz min:, xyz.min(axis0)) print(xyz max:, xyz.max(axis0)) print(intensity range:, intensity.min(), intensity.max()) return cloud这段代码里最关键的是reshape(-1, 4)它把一维数组按每 4 个 float 切成一个点。如果你拿到的是只存 xyz 的三字段 bin这里要改成reshape(-1, 3)否则坐标会全部错位。我见过有人拿着四字段的 bin 硬套三字段脚本结果点云乱成一团还以为是传感器坏了。再看打印出来的范围如果 z 轴范围是 -2 到 4说明是雷达本体坐标z 向上如果 z 的范围是 -50 到 50那这个文件很可能已经是经过坐标变换后的全局坐标。这种情况转 pcd 前要先想清楚后续节点默认的坐标系是什么不能闷头转完就交给下游。2.3 PCD 的 header 结构决定你能否被正确读取PCD 文件可以简单理解成「一段文本头部 一段点云数据」。头部里写的 FIELDS、SIZE、TYPE、COUNT 必须和后面的实际数据完全一致PCL 才会正确解析。比 FIELDS 更容易出错的是 DATA 这一行它只有两个选项ascii 和 binary。选 ascii 时每个点是一行逗号分隔的文本肉眼友好但文件膨胀明显选 binary 时header 之后直接跟二进制浮点流没有换行分隔也没有行尾标识。我刚写转换脚本时犯过一个典型的错误header 写DATA binary然后用文本方式往文件里写入数据结果 PCL 读出来是空点云。原因就是数据区格式与 header 声明不一致PCL 按二进制流解析却碰到了换行符。另外要注意PCD 的 binary 数据是连续紧密排列的所有点的 x、y、z、intensity 依次铺开不能像某些格式那样有行分隔符。换句话说header 最后一行的换行符之后直接就是第一个点的第一个字节。PCD 头部字段里还有两个常被忽略的项WIDTH 和 HEIGHT。单帧无组织点云通常 WIDTH 等于点数、HEIGHT 等于 1如果 HEIGHT 大于 1PCL 会把点云当成有序点云处理后面很多算法会走不同分支。转换时务必保持HEIGHT 1除非你明确知道自己要做的是有序点云。3. 核心转换实现Python 快速改写法与 C 批量落盘方案3.1 用 struct 思路写一个可直接跑的 Python 转换脚本理解了两种格式的底层差异后转换逻辑其实非常直接读 bin 的 float 数组拼一段 PCD header把字节流写进文件。下面这个脚本改成了带 header 生成的完整版本可以直接保存为bin_to_pcd.py使用。import numpy as np import sys def build_pcd_header(points, fields(x, y, z, intensity)): lines [ # .PCD v0.7 - Point Cloud Data file format, VERSION 0.7, FIELDS .join(fields), SIZE .join([4] * len(fields)), TYPE .join([F] * len(fields)), COUNT .join([1] * len(fields)), WIDTH str(points), HEIGHT 1, VIEWPOINT 0 0 0 1 0 0 0, POINTS str(points), DATA binary, ] return (\n.join(lines) \n).encode() def bin_to_pcd(bin_path, pcd_path): raw np.fromfile(bin_path, dtypenp.float32).reshape(-1, 4) header build_pcd_header(raw.shape[0]) with open(pcd_path, wb) as f: f.write(header) f.write(np.ascontiguousarray(raw, dtypenp.float32).tobytes()) print(fconverted {raw.shape[0]} points - {pcd_path}) if __name__ __main__: bin_to_pcd(sys.argv[1], sys.argv[2])header 生成函数里值得注意的参数是fields。默认写了四个字段如果你只想要 xyz 不要 intensity可以把 fields 改成(x, y, z)这样文件会小四分之一。TYPE 全部是 F 表示浮点SIZE 4 表示单精度 4 字节COUNT 1 表示每个字段一个值这三个参数必须和实际写入的字节宽度一致写错任何一个 PCL 都可能读歪。写入部分用np.ascontiguousarray(raw, dtypenp.float32).tobytes()主要是确保内存布局连续。raw本身就是连续的 float32 数组这行是保险写法。如果你的 bin 文件只有 xyz 三字段只需把reshape(-1, 4)改成reshape(-1, 3)其余不用动。3.2 用 PCL 的 PCDWriter 做在线链路落盘Python 方案适合离线批量转但在线采集程序里一般用 C 直接落盘。如果你想把这步嵌进已有的 C 点云处理链路PCL 的pcl::PCDWriter是比较省事的选择。下面这段代码先从 bin 文件读字节再填充 PCL 的 PointCloud 结构。#include pcl/io/pcd_io.h #include pcl/point_types.h #include fstream #include vector bool bin_to_pcd(const std::string bin_path, const std::string pcd_path) { std::ifstream fin(bin_path, std::ios::binary); if (!fin) return false; fin.seekg(0, std::ios::end); size_t bytes fin.tellg(); fin.seekg(0, std::ios::beg); if (bytes % 16 ! 0) return false; // 每个点 4 * float32 16 字节 std::vectorfloat data(bytes / 4); fin.read(reinterpret_castchar*(data.data()), bytes); size_t n bytes / 16; pcl::PointCloudpcl::PointXYZI cloud; cloud.points.resize(n); for (size_t i 0; i n; i) { cloud.points[i].x data[i * 4]; cloud.points[i].y data[i * 4 1]; cloud.points[i].z data[i * 4 2]; cloud.points[i].intensity data[i * 4 3]; } cloud.width n; cloud.height 1; cloud.is_dense true; pcl::io::savePCDFileBinary(pcd_path, cloud); return true; }这段代码里有一个隐含细节用bytes / 4作为 vector 容量等于一次把整个 bin 文件的所有 float 读进内存避免在循环里反复做小规模fread。如果你的采集帧特别大比如 128 线雷达一帧上百万点文件几十 MB一次性读入问题不大如果想要更省内存可以改成分段读取。savePCDFileBinary会生成二进制 pcd而初学者最容易误用savePCDFileASCII。ASCII 版本生成的 pcd 也能读但体积明显膨胀后面避坑章节会展开说。PCL 的 PointXYZI 内部 intensity 是 floatKITTI bin 的第四个字段正好能直接塞进去不需要额外类型转换。3.3 两种写法怎么选Python 方案优点是短、可读性强、字段调整灵活适合做一次性数据迁移、调试和验证。C 方案适合嵌进采集程序让数据落盘时直接输出 pcd省掉事后批量转的步骤。如果你的采集程序本身已经依赖 PCL直接在采集线程里调用这段代码避免把 bin 写到磁盘再起一个 Python 进程处理。性能上 C 方案省了 Python 解释器开销在帧率高的场景体感差距明显。我一般的做法是先写 Python 脚本把链路跑通确认字段和坐标系没问题再把同样的逻辑移植到 C。这个顺序能少踩很多坑因为 Python 里打印检查比 C 方便得多。4. 批量转换与预处理参数一整个目录扫完顺手把噪点滤掉4.1 用 bash 循环跑完整个目录拿到一批需要转换的 bin 文件最简单的方式是写一个 bash 循环。注意加set -e让脚本在遇到错误时立即停下来否则循环到一半失败还会继续跑下去最后你根本不知道哪些文件是好的。#!/bin/bash set -e in_dirraw_bins out_dirconverted_pcds mkdir -p $out_dir for f in $in_dir/*.bin; do base$(basename $f .bin) python bin_to_pcd.py $f $out_dir/$base.pcd done echo done这段脚本里basename $f .bin会把文件后缀去掉得到纯文件名。如果你目录里还有其他后缀的文件通配符$in_dir/*.bin会帮你挡掉大部分干扰。但这里有个隐性前提你事先已经确认过目录里所有 bin 都是同一字段布局。如果混入了不同雷达的数据这个脚本会照样全部转换出来的 pcd 只有一部分是对的。4.2 带滤波和降采样的批量脚本实际项目里很少有干净的直接转换需求。采集到的 bin 往往带着地面点、远距离离群点和过度密集的重复点直接转成 pcd 会让后续算法既慢又容易误判。所以我通常把转换脚本和预处理写在一起先做直通滤波裁剪空间范围再做体素降采样控制密度。下面这个脚本保存为batch_convert.py可以直接从命令行传参。import numpy as np import os import glob import argparse from bin_to_pcd import build_pcd_header def pass_through(raw, xlim, ylim, zlim): mask np.ones(raw.shape[0], dtypebool) if xlim is not None: mask (raw[:, 0] xlim[0]) (raw[:, 0] xlim[1]) if ylim is not None: mask (raw[:, 1] ylim[0]) (raw[:, 1] ylim[1]) if zlim is not None: mask (raw[:, 2] zlim[0]) (raw[:, 2] zlim[1]) return raw[mask] def voxel_downsample(raw, leaf): if leaf 0: return raw keys np.floor(raw[:, :3] / leaf).astype(np.int64) _, idx np.unique(keys, axis0, return_indexTrue) return raw[idx] def main(): ap argparse.ArgumentParser() ap.add_argument(--in_dir, requiredTrue) ap.add_argument(--out_dir, requiredTrue) ap.add_argument(--leaf, typefloat, default0.0, helpvoxel size in meters, 0 disables) ap.add_argument(--xlim, nargs2, typefloat, defaultNone) ap.add_argument(--ylim, nargs2, typefloat, defaultNone) ap.add_argument(--zlim, nargs2, typefloat, defaultNone) args ap.parse_args() os.makedirs(args.out_dir, exist_okTrue) for bin_path in sorted(glob.glob(os.path.join(args.in_dir, *.bin))): raw np.fromfile(bin_path, dtypenp.float32).reshape(-1, 4) raw pass_through(raw, args.xlim, args.ylim, args.zlim) raw voxel_downsample(raw, args.leaf) name os.path.basename(bin_path).replace(.bin, .pcd) out_path os.path.join(args.out_dir, name) header build_pcd_header(raw.shape[0]) with open(out_path, wb) as f: f.write(header) f.write(np.ascontiguousarray(raw, dtypenp.float32).tobytes()) print(f{bin_path} - {out_path} points{raw.shape[0]}) if __name__ __main__: main()pass_through函数做的是直通滤波m 系列参数按顺序对应 x、y、z 的[min, max]。注意这里mask 的写法会把每个维度的条件叠加缺省维度不动。voxel_downsample用np.floor(raw[:, :3] / leaf)计算每个点落在哪个体素格子然后np.unique(..., axis0, return_indexTrue)只保留每个格子里第一个点。这是一个最省内存的近似降采样适合快速处理。如果要求每个体素里做平均可以换成 Open3D 或 PCL 的 VoxelGrid效果更平滑但依赖更重。在命令行里的典型用法是python batch_convert.py --in_dir raw_bins --out_dir filtered_pcds \ --leaf 0.1 --xlim -50 50 --zlim -2 54.3 参数速查表与滤波顺序滤波参数直接决定 pcd 出来能不能用我给一个参考范围实际值取决于你的传感器和场景。参数参考值适用场景副作用leaf0.02 ~ 0.05离线建图、精细标注点数降幅小文件偏大leaf0.1 ~ 0.2实时配准、粗略障碍物检测近距离细节丢失xlim-50 ~ 50前向为主的道路采集丢侧向点ylim-50 ~ 50车体周边通用丢远距离横向点zlim-2 ~ 3普通乘用车雷达安装高度丢高架桥面点zlim-5 ~ 10卡车或高底盘场景地面带得更宽这里有个筛选顺序问题一定是先做直通滤波再做体素降采样。原因是降采样会遍历所有占据的格子如果先把远处的孤立点裁掉格子的数量会明显减少计算量也能降下来。反过来处理的话那些会在地面以下乱窜的离群点还会被体素化保留等于白算。5. 避坑记录我在这条链路上翻过的五个车5.1 转出来 pcd 是空的PCL 读不到任何点现象转换脚本正常跑完生成的文件大小看着也对但用 PCL 读取时点数总是 0。原因最典型的是 PCD header 在 DATA 声明之后多了一个空行。PCL 的 binary 解析逻辑是在 header 中找到DATA binary那行然后把下一个字节当作点云数据起点。如果 header 生成时用了\n\n结尾那个多余的空行会被当成第一个点的前两个字节解析瞬间错位。另一个常见原因是数据区实际是 ASCII 文本但在 header 里声明了 binaryPCL 按二进制解析文本内容读到一堆不可见字符。解决header 拼接时只留一个换行符不要把DATA binary后面再加\n。我习惯在转换脚本里做完后立即打印拼接结果的最后几行确认DATA binary后面没有多余空行。写完后用解析器回读一次单独验证。5.2 坐标乱飞点云里出现大量 NaN 和异常值现象转出来的 pcd 点数和 bin 对得上但可视化里点云像炸开的烟花很多点距离传感器几百米还有些点坐标是 NaN。原因字段布局判断错了。有人拿到的 bin 其实是五字段或六字段浮点数组多出来的是时间戳或反射脉宽等信息却用每点 4 个 float 去切片导致后续所有点错位。另一种情况是 bin 文件里本身就有 NaN 点激光雷达打在吸收材质上或者某些反射面会出现无效测量这些点不处理会一路带到 pcd 里。解决严格按文件大小判断字段数不要猜。237M 大小除以 16 能整除但打印出来的坐标量级完全不合理这就是字段数判定出错的信号。对 NaN 点转换前加一行raw raw[np.all(np.isfinite(raw), axis1)]把含非有限值的点整行去掉再做后续处理。5.3 pcd 文件体积突然膨胀好几倍现象同样的点数量bin 文件 50MB转出来的 pcd 变成 180MB。原因几乎所有刚写转换脚本的人都会遇到。PCL 的savePCDFileASCII默认把每个点写成一行 ASCII 文本同样的 float32 数据用文本表示体积大约膨胀 3 到 4 倍。如果你自己写 header 时把DATA binary写成了DATA ascii效果一样。解决落盘时用savePCDFileBinary或者自定义 header 里明确写DATA binary。这里有个判断技巧用文本编辑器打开生成的 pcd如果文件里能看到大量小数点那生成的就是 ASCII 版本。正确的 binary pcd 在数据区是不可读的二进制内容。5.4 点云前后倒置左右镜像怎么看怎么不对劲现象pcd 里的场景轮廓清晰但车辆行驶方向对着 z 轴而 bin 数据里方向对着 x 轴整体转了个 90 度。原因坐标系约定不一致。KITTI 风格的 bin 坐标通常是雷达本体坐标x 向前、y 向左、z 向上但有些采集工具链会把点云存成相机坐标z 向前、x 向右。这个信息不会写在 bin 文件里完全要靠经验判断。解决转换前先打印前几个点的坐标判断朝向而不是盲目相信文件后缀。如果确认是坐标系旋转问题需要在 reshape 后对 xyz 部分做矩阵旋转intensity 不受影响。具体旋转矩阵根据你的坐标系定义推导常见的从相机坐标转雷达坐标是绕 y 轴转 90 度不要随便套网上的矩阵。这个我一般会单独写一个transform参数不在转换脚本里写死。5.5 批量转换跑到一半崩掉或者静默跳过一半文件现象循环脚本执行完输出目录里 pcd 不全主进程报ValueError或直接被系统 kill。原因目录里混进了一个损坏的 binnp.fromfile读到的 float 数量不是 4 的倍数reshape 抛错。另一个常见原因是脚本把所有文件路径先收集到列表再统一读取转换当文件有上百个且每个几十 MB 时内存被瞬间打满系统触发 OOM。解决批量脚本里用try / except包住单个文件的转换逻辑捕获到异常时打印当前文件名然后continue不要让一个坏文件拖垮整个批次。同时循环里逐文件处理处理完一个就释放一个不要让raw变量变成长生命周期的大数组。我的习惯是每处理一个文件就主动del raw必要时再加gc.collect()。6. 转换后的验证回读点数、抽点对比与可视化速查6.1 回读 PCD 并核对 POINTS转换完不等于转换对。我每次批量转换完都会随机抽三个文件做回读校验把 pcd 里的点数和坐标与 bin 原始值对比。下面这段代码读取 PCD 的头部POINTS字段再从二进制数据区解析实际点数。import numpy as np def verify_pcd(pcd_path): with open(pcd_path, rb) as f: content f.read() head, sep, body content.partition(bDATA binary\n) header_text head.decode(errorsignore) points_field [line for line in header_text.splitlines() if line.startswith(POINTS)][0] declared int(points_field.split()[1]) actual np.frombuffer(body, dtypenp.float32).reshape(-1, 4).shape[0] print(fdeclared{declared} actual{actual}) assert declared actual校验规则很简单声明点数必须等于实际数据区解析出来的点数。若不等说明 header 的 WIDTH 或 POINTS 写错了或者是数据区本身有问题。这个检查脚本很值得保留它能在调整滤波参数时快速发现点被滤得过狠造成点数畸变的问题。6.2 可视化目检数值校验过了还要用眼睛过一遍。有 PCL 环境的直接用 pcl_viewer 打开pcl_viewer output.pcd打开后按a居中显示用和-调整点大小用鼠标拖旋转视角。目检重点看三处地面是否在一个平面上、点云前后方向是否符合预期、远处是否有异常离群点。如果没有 PCL 环境Open3D 的一行也能搞定import open3d as o3d pcd o3d.io.read_point_cloud(output.pcd) o3d.visualization.draw_geometries([pcd])Open3D 的方便之处在于能直接读 binary pcd不需要额外转换。如果两个工具加载出来的场景差异很大优先怀疑 pcd 的 header 字段写错了。6.3 多帧拼接前先乘位姿再合并最后提醒一个我吃过大亏的操作把多帧 bin 转成一个大 pcd 做离线地图时不要先转 pcd 再拼接更不要在拼接时才做坐标变换。正确做法是先把每帧 bin 的点云乘上对应位姿矩阵变换到统一坐标系后再转 pcd。理由很直接pcd 只是静态载体它自身不带位姿信息多帧点云如果带着各自的传感器坐标系直接拼场景会错开几米到几十米不等。我自己习惯在转换脚本里预留一个pose_path参数每读一帧 bin 就同步读对应位姿先变换后落盘。从那以后我每次做批量转换都会强制走一遍「读 bin 核对布局 → 转换落盘 → 回读点数 → 随机抽点对比 → 可视化目检」的完整链路再也不信任裸的转换输出。完整的单文件转换、批量带滤波脚本和校验工具都在这份配套资源里下载后直接对着自己的 bin 跑一遍就能看到效果希望帮到你。本文还有配套的精品资源点击获取