简介自动驾驶端到端数据集压缩包基于CAN总线采集的原始车辆与传感器数据整理而成面向自动驾驶算法工程师、科研人员及机器学习学习者可用于端到端驾驶模型训练、传感器融合验证与控制策略优化。压缩包内含2000个JSON格式文件整体约744.8MB每个文件对应一个场景下CAN总线记录的传感器信号与车辆状态数据便于按场景索引与批量解析。文件命名保留了场景编号与采集设备信息目录结构规整适合直接对接常见数据处理流程。当前已有126人学习下载资源内容聚焦于车辆速度、转向、油门制动以及雷达、激光雷达、摄像头等感知数据并附有诊断信息可用于仿真测试与实车数据对比分析。研究者可借此开展数据清洗、特征工程、模型训练与仿真验证能有效降低采集成本并加速算法迭代为构建更安全、更智能的自动驾驶系统提供数据基础。 做嵌入式这些年我下载过的压缩包比吃过的盐都多。can_bus.zip这种命名一看就是某个 CAN 总线项目打包后的交付物——可能是 STM32 的收发例程可能是 USB-CAN 分析仪的配套固件也可能是一整套报文解析脚本。今天我就拿这个典型的命名当标本从头到尾走一遍怎么安全解压、怎么识别工程结构、怎么把 CAN 代码编译烧录进板子、最后怎么用上位机验证总线收发。这篇文章里会穿插我在各个技术群里被反复问过的坑解压报 EOCD 错误、z01 分卷文件不识别、zip 密码忘了、GitHub 上下载的工程和 git 仓库关联不上、波特率对不上、终端电阻忘接。无论你是刚接触 CAN 通信的学生还是已经在车上调过几天报文的老手接下来这些内容应该都有你能直接用上的部分。1. 先看门牌号can_bus.zip 到底是什么东西1.1 三种最常见的包内结构拿到一个叫can_bus.zip的文件先别急着双击解压。这个命名风格在嵌入式交付里太典型了通常情况下包里装的是下面三类东西之一MCU 源码工程最常见的是基于 STM32 的 CAN 收发例程配合 TJA1050、MCP2551 或 SN65HVD230 这类收发器演示标准帧和扩展帧的收发工程文件一般用 Keil 或 STM32CubeIDE 打开。USB-CAN 工具的驱动或固件比如兼容 canable、candleLight 的开源 USB-CAN 适配器固件还有周立功 USBCAN 系列的上位机安装包这类包解压后通常是 exe 安装程序或需要烧录进板子的 bin/hex 文件。脚本或报文解析工具Python 写的 can 总线抓包解析脚本或者 DBC 信号定义文件、CAN 报文记录文件这类包里通常还会带 requirements.txt 或 README。还有一小部分情况比较特殊can_bus.zip是某个车机、仪表或工控设备的线刷固件包。这个和手机刷机 zip 包是一个逻辑——像 HTC One M7 的线刷 zip里面是非常规的文件系统镜像直接解压是没法使用的得配合厂商的刷机工具走一遍线刷流程。所以收到包之后第一件事是找 README 和版本说明文件。没有 README 的话就看顶层目录名和文件后缀.uvprojx是 Keil 工程.ioc是 CubeMX 配置.hex/.bin是烧录镜像.py/.dbc是上位机或分析脚本。1.2 解压阶段的高频坑解压这个步骤看着简单我实际遇到的翻车现场比编译报错还多。先说最著名的错误invalid zip archive: could not find EOCD。EOCD 是 zip 格式末尾的一条中央目录结束标记相当于整份压缩包的封条。出现这个错误九成原因是文件下载不完整——多线程下载器、浏览器中断、服务器断流都会让文件尾部缺失。解决办法很简单删掉重新下载优先用浏览器单线程直接保存。如果你用的是某个大型 IDE 或资源包导入功能报这个错比如导入资源包时提示could not find eocd大概率也是源文件被中间环节截断了重新获取源文件最省事。第二个高频问题是分卷压缩包zip 解密和 z01 系列文件。假设你下载的文件是can_bus.z01加can_bus.zip这种组合Windows 自带的解压工具直接双击主 zip 就会提示文件损坏。这不是文件真的坏了是系统自带工具不支持 z01/z02 分卷拼接。解决办法是用 7-Zip 或 Bandizip 打开主.zip文件同目录下的.z01会被自动识别合并。如果你只拿到一个孤零零的z01文件那就得像找 zip 本体一样去下载源重新补齐分卷缺任何一卷都没法完整解出内容。第三个坑是加密 zip。有些项目包发布时会套一层密码比如固件包、线刷包为了防止误传作者会设个简单密码并写在说明页里。如果你手上的压缩包带了密码又找不到来源可以试试百事牛 ZipPassword 这类密码恢复工具用纯数字或短单词的字典模式跑一下速度快且大概率能出结果。但这里我必须多说一句这类工具仅限用于找回自己加密的文件去破解别人分发的资源既不合适也不安全。如果密码是七八位以上大小写加符号的强密码暴力破解基本无望精力不如花在找原始发布渠道上。解压后第一个动作建议把整个工程目录挪到纯英文路径下比如D:\can_bus_proj。Keil、IAR、CubeMX 这些老牌工具链对中文路径和空格目录的兼容性极差编译时冒出莫名其妙的 cannot open source file 或 failed to copy 类报错查半天最后发现是路径问题太浪费生命了。顺带一提如果你的电脑上装了某些国产全家桶压缩软件系统里多了一堆弹窗和右键菜单建议直接卸载用 7-Zip 开源的命令行 图形界面就够用了没有广告没有捆绑。2. 解压之后源码工程怎么识别与还原2.1 目录结构速览认出这是一个正统的 CAN 工程解压出来之后的文件结构能直接透露这个工程是用什么工具链创建的。一个典型的 STM32 CAN 工程目录大概是这样的can_bus/ ├── Core/ │ ├── Inc/ │ └── Src/ │ ├── main.c │ ├── can.c │ └── gpio.c ├── Drivers/ │ ├── CMSIS/ │ └── STM32F1xx_HAL_Driver/ ├── Hardware/ │ └── can_board.c ├── MDK-ARM/ │ ├── can_bus.uvprojx │ └── can_bus.hex └── can_bus.ioc看到ioc文件基本可以确定是 STM32CubeMX 生成的工程MDK-ARM目录说明作者用 Keil 开发。Hardware这个自定义文件夹往往藏着板级适配代码比如开发板上 CAN 收发器的使能引脚、LED 指示灯的初始化等等。看 CAN 相关代码也是这个套路can.c文件里通常是一组 HAL 库函数调用static void MX_CAN_Init(void) { hcan.Instance CAN1; hcan.Init.Prescaler 4; hcan.Init.Mode CAN_MODE_NORMAL; hcan.Init.SyncJumpWidth CAN_SJW_1TQ; hcan.Init.TimeSeg1 CAN_BS1_9TQ; hcan.Init.TimeSeg2 CAN_BS2_8TQ; hcan.Init.TimeTriggeredMode DISABLE; hcan.Init.AutoBusOff DISABLE; hcan.Init.AutoWakeUp DISABLE; hcan.Init.AutoRetransmission ENABLE; hcan.Init.ReceiveFifoLocked DISABLE; hcan.Init.TransmitFifoPriority DISABLE; if (HAL_CAN_Init(hcan) ! HAL_OK) { Error_Handler(); } }这里有个很重要的计算点CAN 的波特率不是某个寄存器直接写出来的而是由 APB1 外设时钟经过预分频器和时间段参数共同决定的。以 STM32F103 为例APB1 时钟通常是 36MHz要得到 500kbps 的标准总线速率需要满足36MHz / (Prescaler * (1 TimeSeg1 TimeSeg2)) 500kbps。代入上面代码就是36MHz / (4 * (1 9 8)) 500kbps两组参数相乘恰好等于 72。如果你拿到手的工程波特率和你对端设备不一致常见的有 125k、250k、500k、1M改这里就行改完记得重新生成擦除烧录整个程序。2.2 GitHub 下载的 zip 如何和 git 仓库重新建立关系很多can_bus.zip是从 GitHub 仓库直接打包下载的。这种 zip 是源代码快照里面没有.git目录也就是说它和原来的 git 仓库没有任何关联。如果你后续想在这个工程上继续开发、提交修改、再同步回远端就得手动把关系建立起来cd can_bus # 初始化本地仓库 git init # 添加远端地址 git remote add origin https://github.com/yourname/can_bus.git # 拉取远端历史并切换分支 git fetch origin git checkout -b main origin/main实际操作中变基到远程仓库失败是群里问得最多的。原因通常是本地仓库先有了自己的提交比如你解压后直接改代码并 commit 了远端也有新内容两边历史没有任何交集时git rebase origin/main就会报冲突或拒绝操作。这种情况我建议按顺序处理先git fetch再git rebase origin/main如果冲突太大就把自己本地不必要的提交先git reset --soft origin/main保留改动再重新提交比硬解冲突省事得多。如果那个打包的作者没有在仓库里放.gitignore解压目录里还可能有build/、MDK-ARM/Listings/这类临时生成文件关联仓库前最好补一个.gitignore别把编译中间产物一起提交上去。2.3 依赖和固件包ST 官网下载对应固件 zip 包的逻辑如果工程不是用 CubeMX 生成的而是作者从 ST 官网下载的固件包改出来的那么编译时经常会遇到缺头文件或缺 HAL 库源文件的问题。STM32 官方把 HAL 库整理成了压缩包比如 STM32CubeF1、STM32CubeF4、STM32CubeH7 系列固件包官网下载下来同样是个大 zip。解压这些固件包的时候路径里一定不能有中文而且文件夹名里的版本号、型号后缀都不要手工去改很多工程在.ioc文件或者编译器包含路径里写死了固件包的相对位置改名字等于自断后路。使用 CubeMX 的读者更顺的做法是打开工程里的.ioc文件CubeMX 会提示你重新生成完整工程代码。首次打开时如果提示找不到对应系列的固件包在 Preferences 里设置好你已经解压的固件包路径就行。这里有个经验重新生成代码会覆盖main.c里自动生成区域的代码你自己写在/* USER CODE BEGIN */以外的部分会被抹掉所以一定要现把main.c备份一份再操作。3. 编译烧录让 CAN 代码跑起来3.1 工具链选择与工程打开can_bus.zip里最常见的工程形式是 Keil 的.uvprojx直接用 Keil MDK 打开就能编译。没有 MDK 的话STM32CubeIDE基于 Eclipse GCC也能导入这类工程但导入过程需要手动指定 MCU 型号和调试器类型新手容易在导入向导里卡住。我的建议是如果只是改了 CAN 参数、验证一下收发Keil 是最省事的选择如果要长期维护这个项目建议把工程整体迁移到 CMake GCC 体系编译速度更快也方便接入 CI。编译之前先检查三处设置C 编译器版本是否过旧、Include Paths 是否包含Core/Inc和Drivers目录、宏定义里是否写了正确的芯片型号比如STM32F103xB。这三项没问题F1 系列这类小型工程通常几秒钟就能编过。如果报failed to copy或cannot open file先核对路径再看杀毒软件是不是把临时目录里的文件锁住了。3.2 硬件接线这几根线千万别接错代码编过之后先别急着烧录看一下硬件。CAN 总线物理层是两条差分线 CAN_H 和 CAN_L加上共地线 GND。这个千万不能接反接反了总线完全瘫痪而且故障表现很迷惑——调试器连得通程序也在跑就是收不到任何报文。一般的开发板或核心板上已经集成了 CAN 收发器你只需要确认几个点CAN_H 接 CAN_HCAN_L 接 CAN_L两个节点之间还要拉一根 GND 共地。收发器供电是否正确5V 还是 3.3V看具体型号手册。终端电阻的规则CAN 总线要求在物理两端各接一个 120 欧姆电阻。如果你是两块开发板对接只需要在总线一头接一个 120 欧姆电阻即可。如果用了 USB-CAN 分析仪要确认分析仪内部是否已经带了 120 欧姆终端电阻有些分析仪有个跳帽或拨码开关可以切换两边都接了 120 欧姆并联起来等效 60 欧姆通信质量反而会下降。你自己手搓硬件的话用 TJA1050 或 MCP2551 做收发器最稳MCP2551 是 DIP 封装适合洞洞板TJA1050 是 SOIC 封装贴片焊接稍麻烦但兼容性好。有些低价板子用的是 3.3V 供电的 SN65HVD230这个时候如果接到 5V 总线上需要确认电平兼容设计否则总线隐形时可能出现异常位。3.3 烧录与首次运行烧录用最常见的 ST-Link V2 就行四根线SWDIO、SWCLK、GND、3V3。连接好后Keil 里点 Download 按钮如果提示No target connected依次检查驱动、接线、板子供电最后考虑是不是目标芯片的读保护被打开了。烧录完成后开发板断电重新上电程序开始跑。首次上电我习惯在MX_CAN_Init之后加上一句HAL_CAN_Start(hcan)并在主循环里通过串口打印 CAN 控制器的状态。如果 HAL_CAN_Start 返回值不是 HAL_OK多半是初始化参数有问题优先看 CAN 的 GPIO 配置是否把 PA11/PA12 复用了很多板卡上的 CAN 引脚不是默认的 PA11/PA12需要按原理图去改MX_CAN_GPIO_Init里的引脚配置。串口打印正常、状态寄存器显示 active就说明控制器层面已经跑起来了可以进入下一步总线调试。4. 上总线调试报文收发与排查实录4.1 先测自发自收在接线不复杂、只有一块开发板的情况下先做回环测试。把 CAN 工作模式从CAN_MODE_NORMAL改成CAN_MODE_LOOPBACK总线不依赖外部节点MCU 自己发出的报文会直接进入自己的接收 FIFO这是验证代码逻辑最快的方式。配置好滤波器之后用 HAL 库发一帧标准帧CAN_TxHeaderTypeDef TxHeader; uint8_t TxData[8] {0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08}; uint32_t TxMailbox; TxHeader.DLC 8; TxHeader.IDE CAN_ID_STD; TxHeader.RTR CAN_RTR_DATA; TxHeader.StdId 0x123; HAL_CAN_AddTxMessage(hcan, TxHeader, TxData, TxMailbox);如果接收中断配置正确在HAL_CAN_RxFifo0MsgPendingCallback里能读到同一帧数据。回环测试通过说明控制器、波特率、过滤器、中断这整套链路都是通的问题如果存在就只在物理层和对端节点。4.2 双节点对接与上位机抓包回环通了之后把模式改回CAN_MODE_NORMAL接入 USB-CAN 分析仪或另一块开发板进行双节点对接测试。买一个兼容 candleLight 固件的 USB-CAN 适配器相当便宜配上 BUSMASTER 或官方的 CANTest 上位机就能直接抓包和分析报文。连接时先确认总线波特率一致——开发板代码里的预分频和时间段参数决定了节点速率上位机软件里也要选择同样的 500k 或 250k。两边都是 500k 时CANTest 点打开设备后开发板主动发送的报文会显示出来ID 0x123、8 个字节、计数递增都能看到。然后反向测用上位机发送一帧 0x456 的报文看 MCU 端中断有没有触发收到后串口打印出来。这个双向测试通过了你的 CAN 基础链路就稳了。如果对端的报文带有 DBC 信号定义建议直接用 BUSMASTER 加载 DBC 文件把原始报文解码成物理量比如车速、转速、油门开度。这个习惯对汽车电子场景特别重要裸看十六进制报文头会晕DBC 解码之后调试效率直接翻倍。4.3 经典故障速查表把这些年在 CAN 调试上遇到过的典型问题整理成一张表出问题的时候按顺序排查现象可能原因排查方法完全收不到报文CAN_H/CAN_L 接反万用表量两端电压正常情况下 CAN_H 约 2.5VCAN_L 约 2.5V通信时差分电压明显变化完全收不到报文波特率不匹配用分析仪抓总线波形看位时间宽度确认两边统一 500k/250k/125k间歇性通信错误缺少终端电阻或电阻位置不对用示波器看总线波形无终端电阻时信号回波毛刺明显用万用表量总线两端阻值应为 60 欧姆左右初始化后 HAL_CAN_Start 失败CAN 引脚复用错误或时钟没被使能检查 GPIO 的 AFIO 设置对照板卡原理图确认引脚发送失败且错误计数器增长总线上有其他节点波特率不匹配或帧格式冲突打开分析仪看错误帧识别出报错的节点 ID上位机能收MCU 收不到过滤器配置不当把过滤器设置为 IDMASK 模式全接受逐一排查Kali/Linux 下解压 zip 中文乱码压缩包使用了 Windows 编码用unzip -O CP936 file.zip指定编码重新解压最后一个乱码问题很多资深工程师也容易忽略。从 Windows 环境打包出来的 zip如果文件名带中文在 Linux 下直接unzip会显示成乱码。这不是文件真坏了是 zip 规范里没有明确文件名编码Windows 默认用 GBKLinux 默认按 UTF-8 解析。用 7-Zip 的命令行7z x can_bus.zip也可以规避一部分编码问题但最稳妥的还是让发布方把中文文件名改成英文再打包。5. 最后分享一点实践体会我处理过的can_bus.zip类项目少说也有几十个最大的感受是这个包名的项目质量参差得非常厉害。有的作者在压缩包里放了详细的 README、接线图、版本变更记录解压就懂有的则只有一个裸的工程文件和一堆编号不明的脚本全凭猜。所以如果你是自己打包发布 CAN 工程建议至少做到三件事写清楚芯片型号和硬件接线写明编译工具链版本README 里附上波特率和过滤器配置位置。打包时用zip -r can_bus_v1.0.0.zip can_bus/这样的命令生成带版本号的包别再用笼统的can_bus.zip了。调试 CAN 总线这件事本质上是在和时间打交道——波特率、位时序、仲裁优先级全是时序问题。我个人的习惯是优先把上位机分析仪养好所有节点收发的报文都必须肉眼可见再去碰业务逻辑。总线上的报文一旦是黑盒状态排查问题基本靠猜效率极低。把上面的基础链路走通一遍后面不管是做车载报文解析、工业设备通信还是自己造一个小型分布式控制系统都会顺很多。本文还有配套的精品资源点击获取