简介：本资源面向车路协同与智能网联汽车开发者，聚焦V2X基础功能实现，涵盖OBU车载单元与RSU路侧单元，并集成FCWS前向碰撞预警及完整V2X协议栈，适合具备C/C++与嵌入式基础的中高级工程师用于协议栈移植、联调与二次开发。压缩包共5199个文件，约219.61MB，以C源码与头文件为主体，辅以Java、C++、Python脚本及ASN.1定义文件，另有大量编译产物、动态库、配置与日志文件，完整呈现协议栈从源码到可运行工程的目录结构。已有2784人学习下载，说明该方案在车联网学习与项目实践中具备较高参考价值。读者可据此梳理OBU与RSU通信流程、消息编解码与预警逻辑，快速搭建可编译运行的V2X实验环境，并借助现有模块定位协议交互与编译链接中的常见问题。
1. 车路协同到底怎么落地：从 OBU 到 RSU 的一条完整数据链路
很多人第一次接触 V2X，脑子里浮现的是“车跟车说话”“车跟红绿灯说话”这种模糊概念。但真到项目里，问题立刻变得具体：OBU 怎么把自己的位置和状态广播出去？RSU 收到之后怎么处理、怎么转发、怎么和信号灯相位对齐？协议栈里 WSMP、BSM、SPaT 这些缩写到底谁调谁？我见过不少团队把 V2X 当成“加个无线模块”的事，结果联调时发现消息根本对不上，最后翻车在协议栈配置上。这个项目做的就是 OBU 和 RSU 两端的最小可运行实现，把 V2X 协议栈从抽象标准拉到能跑通的代码层面。它适合两类人：一是刚接手车路协同模块、需要快速理解消息流转的开发者；二是想拿一套可编译、可改参数的 OBU/RSU 参考实现做二次开发的人。下面按“先看清结构、再跑起来、最后能改”的顺序拆。
2. 协议栈与模块拆解：OBU 和 RSU 各自在干什么
2.1 整体架构：两层设备、三条消息流
这个项目的架构不复杂，但分工很明确。OBU 侧负责车载端的数据采集、消息封装和广播；RSU 侧负责路侧接收、消息解析、事件判断和回传。两端共用一套 V2X 协议栈，区别在于应用层逻辑和硬件接口。
从数据流看，核心是三条线：
- BSM 广播流：OBU 周期性生成 Basic Safety Message，包含经纬度、速度、航向角、刹车状态等，通过 PC5 接口广播出去。
- SPaT/MAP 下行流：RSU 从信号机或本地配置获取相位信息，封装成 SPaT 消息，配合 MAP 消息描述路口几何，广播给覆盖范围内的 OBU。
- 事件回传流：RSU 收到 OBU 的 BSM 后，做碰撞风险判断或区域统计，必要时生成 RSI 消息回传。
协议栈分层上，底层是接入层（PC5 或 802.11p），往上是网络层和传输层（WSMP 或 GeoNetworking），再往上是消息层（SAE J2735 定义的消息集），最上面是应用层。项目里把这几层做了适度简化，但保留了消息编解码和周期调度的核心逻辑。
注意：不同地区对 V2X 底层接入技术的选择不同，项目里通常用配置项切换，不要硬编码在业务逻辑里。
2.2 目录结构：从入口到协议栈的映射
拿到源码后，先看目录，能省很多时间。这个项目的典型结构如下：
v2x-obu-rsu/ ├── common/ # 两端共用 │ ├── codec/ # J2735 消息编解码 │ ├── wsmp/ # WSMP 传输封装 │ └── utils/ # 坐标转换、时间同步 ├── obu/ │ ├── app/ # BSM 生成、周期调度 │ ├── hal/ # 车载接口（CAN/GPS） │ └── main.c ├── rsu/ │ ├── app/ # SPaT 生成、BSM 处理 │ ├── hal/ # 信号机接口、网络接口 │ └── main.c ├── config/ │ ├── obu_config.json │ └── rsu_config.json └── build/common/codec是最值得先读的模块，因为消息编解码错了，后面全白搭。obu/app和rsu/app是业务逻辑集中地，改行为主要在这里。config目录下的 JSON 文件控制设备 ID、广播频率、区域范围等参数，联调时改配置比改代码快。
2.3 核心模块一：BSM 消息的生成与编码
OBU 侧最核心的动作是周期性地把车辆状态封装成 BSM。下面是一段简化后的 BSM 生成代码，保留了关键字段和编码调用：
// obu/app/bsm_sender.c #include "codec/j2735_enc.h" #include "hal/gps.h" #include "hal/can.h" #define BSM_INTERVAL_MS 100 // 10Hz 广播频率 void obu_bsm_task(void *arg) { BsmMessage bsm; VehicleState vs; uint8_t buffer[512]; size_t encoded_len; while (1) { // 1. 从 HAL 层读取车辆状态 gps_get_position(&vs.lat, &vs.lon, &vs.heading); can_get_speed(&vs.speed); can_get_brake_status(&vs.brake); // 2. 填充 BSM 结构体 bsm.msg_id = J2735_BSM; bsm.lat = vs.lat; bsm.lon = vs.lon; bsm.speed = vs.speed; bsm.heading = vs.heading; bsm.brake_status = vs.brake; bsm.timestamp = get_monotonic_ms(); // 3. 调用编解码层进行 UPER 编码 encoded_len = j2735_encode_bsm(&bsm, buffer, sizeof(buffer)); if (encoded_len == 0) { log_error("BSM encode failed"); continue; } // 4. 通过 WSMP 发送 wsmp_send(buffer, encoded_len, WSMP_PSID_BSM); delay_ms(BSM_INTERVAL_MS); } }这段代码的逻辑很直白：读状态、填结构、编码、发送、等下一个周期。关键参数是BSM_INTERVAL_MS，标准里 BSM 通常是 10Hz，但拥堵场景下有些实现会动态调整到 5Hz 或更低来减少信道占用。j2735_encode_bsm内部做的是 UPER 编码，这是 J2735 消息的标准编码方式，如果这里返回 0，优先检查结构体里有没有超出范围的值，比如经纬度精度不够或速度字段溢出。
wsmp_send的第三个参数是 PSID，BSM 对应的是WSMP_PSID_BSM，这个值在 RSU 侧接收时要匹配，否则消息会被丢弃。联调时如果 RSU 收不到 BSM，先查 PSID 是否一致。
2.4 核心模块二：RSU 侧的消息接收与 SPaT 生成
RSU 侧的逻辑分两块：一块是收 BSM 并处理，另一块是生成 SPaT 并广播。先看接收处理：
// rsu/app/bsm_handler.c #include "codec/j2735_dec.h" #include "app/risk_judge.h" void rsu_on_bsm_received(const uint8_t *data, size_t len) { BsmMessage bsm; int ret; // 1. 解码 BSM ret = j2735_decode_bsm(data, len, &bsm); if (ret != 0) { log_warn("BSM decode failed, drop"); return; } // 2. 更新本地车辆列表 vehicle_list_update(&bsm); // 3. 风险判断 if (risk_judge_check(&bsm) == RISK_HIGH) { rsi_trigger(&bsm); // 触发 RSI 消息 } }解码失败直接丢弃，这是常见做法，因为 V2X 环境里消息量大，不能因为一条坏消息阻塞后续处理。vehicle_list_update维护一个带超时的车辆列表，超时时间一般设 2 到 3 秒，超过就认为车辆已离开覆盖范围。risk_judge_check是业务逻辑，项目里可能只做了简单的距离和速度判断，二次开发时可以替换成更复杂的算法。
再看 SPaT 生成：
// rsu/app/spat_sender.c #include "codec/j2735_enc.h" #include "hal/spat_source.h" #define SPAT_INTERVAL_MS 200 // 5Hz void rsu_spat_task(void *arg) { SpatMessage spat; uint8_t buffer[512]; size_t encoded_len; while (1) { // 1. 从信号机或本地配置获取相位 spat_source_get(&spat); // 2. 填充 SPaT 结构体 spat.msg_id = J2735_SPAT; spat.timestamp = get_monotonic_ms(); // 3. 编码并广播 encoded_len = j2735_encode_spat(&spat, buffer, sizeof(buffer)); if (encoded_len > 0) { wsmp_send(buffer, encoded_len, WSMP_PSID_SPAT); } delay_ms(SPAT_INTERVAL_MS); } }SPaT 的广播频率通常比 BSM 低，5Hz 左右够用，因为信号灯相位变化没那么快。spat_source_get是硬件抽象层，实际项目里可能从信号机控制器读，也可能从本地配置文件读，联调时如果拿不到真实信号机，用配置模拟就行。
2.5 配置与参数：改哪里、怎么改
配置文件是联调时最常动的地方。以obu_config.json为例：
{ "device_id": 1001, "bsm_interval_ms": 100, "tx_power_dbm": 20, "region": { "lat": 31.2304, "lon": 121.4737, "radius_m": 300 }, "wsmp": { "psid_bsm": 32, "psid_spat": 33 } }device_id在联调时必须唯一，否则 RSU 侧车辆列表会覆盖。tx_power_dbm影响覆盖范围，室内测试时调低到 10 以下避免干扰。region里的经纬度是广播区域的中心点，radius_m控制范围，测试时如果设备不动，可以把半径设小一点减少无关消息。psid_bsm和psid_spat必须和 RSU 侧配置一致，这是最常见的“收不到消息”原因。
3. 跑起来：从编译到两端联调的完整步骤
3.1 环境准备与编译
项目通常是 C/C++ 代码，依赖标准库和少量第三方库（如 JSON 解析、日志库）。编译前先确认工具链：
# 安装基础依赖（以 Ubuntu 为例） sudo apt update sudo apt install build-essential cmake libjson-c-dev # 进入项目目录 cd v2x-obu-rsu # 创建构建目录并编译 mkdir -p build && cd build cmake .. make -j4编译产物在build/下，通常生成obu和rsu两个可执行文件。如果编译报错找不到头文件，检查CMakeLists.txt里的include_directories是否包含了common/和对应模块的路径。常见问题是codec目录下的头文件引用路径写成了相对路径，在不同机器上会挂，改成基于项目根目录的路径更稳。
3.2 单端启动：先让 OBU 自己跑起来
不要一上来就两端联调，先让 OBU 单端运行，确认 BSM 能正常生成和编码：
# 启动 OBU，指定配置文件 ./obu -c ../config/obu_config.json -l debug-c指定配置，-l debug打开调试日志。正常运行时日志里会周期性打印 BSM 编码成功的信息，包含经纬度、速度和时间戳。如果日志里出现BSM encode failed，先检查 GPS 和 CAN 的模拟数据是否在合理范围内。项目里通常有模拟模式，配置里加"simulation": true就能用固定值代替真实硬件。
RSU 单端启动类似：
./rsu -c ../config/rsu_config.json -l debugRSU 启动后会先加载 MAP 消息（如果配置里有），然后开始周期性广播 SPaT。日志里会看到SPaT sent和BSM received的记录。如果只有发送没有接收，说明 OBU 那边还没启动或者 PSID 不匹配。
3.3 两端联调：验证消息闭环
两端都跑起来后，验证闭环的关键是看 RSU 是否收到了 OBU 的 BSM，以及 OBU 是否收到了 RSU 的 SPaT。最直接的方法是看日志：
# 在 RSU 日志里过滤 BSM 接收记录 grep "BSM received" rsu.log | tail -20 # 在 OBU 日志里过滤 SPaT 接收记录 grep "SPaT received" obu.log | tail -20如果 RSU 侧有 BSM 接收但 OBU 侧没有 SPaT 接收，检查 RSU 的发送功率和 OBU 的接收频率是否匹配。如果两边都收不到，优先查 PSID 和区域配置。联调时建议把region.radius_m设大一点，比如 1000 米，确保设备在范围内。
提示：联调阶段可以把 BSM 和 SPaT 的间隔都调大，比如 BSM 改成 500ms，SPaT 改成 1000ms，减少日志量，方便定位问题。
3.4 用抓包和日志定位问题
如果日志不够，可以在 WSMP 发送和接收的地方加计数：
// 在 wsmp_send 和 wsmp_receive 里加统计 static uint32_t tx_count = 0; static uint32_t rx_count = 0; void wsmp_send(...) { tx_count++; // ... 原有逻辑 } void wsmp_receive(...) { rx_count++; // ... 原有逻辑 }跑一段时间后打印tx_count和rx_count，如果发送远大于接收，说明信道或配置有问题。常见原因是发送功率太低、接收灵敏度不够，或者两端用的信道不一致。项目里如果支持信道配置，确认channel字段两边一致。
4. 避坑与常见问题：联调时最容易翻车的几个点
4.1 消息收不到：PSID 和信道不匹配
现象：RSU 日志里完全没有 BSM 接收记录，或者 OBU 完全收不到 SPaT。
原因：最常见的是 PSID 配置不一致。BSM 和 SPaT 各有自己的 PSID，发送端和接收端必须匹配。其次是信道不一致，V2X 通常用特定信道，两端配成不同信道就收不到。
解决：先核对obu_config.json和rsu_config.json里的psid_bsm、psid_spat和channel字段，确保完全一致。改完配置后重启两端。
4.2 编码失败：字段超范围或精度不够
现象：日志里频繁出现BSM encode failed或SPaT encode failed。
原因：J2735 对字段范围有严格定义，比如经纬度用 1/10 微度表示，速度用 0.02 m/s 为单位，如果传入的值超出范围或精度不对，编码就会失败。
解决：在填充结构体之前做范围检查。比如纬度有效范围是 -90 到 90，经度是 -180 到 180，速度不要超过 163.82 m/s。项目里通常在codec层有校验函数，调用一下再编码。
4.3 时间戳不同步：消息被误判为过期
现象：RSU 收到了 BSM，但风险判断模块认为消息过期，不触发任何事件。
原因：OBU 和 RSU 的时间戳基准不一致。BSM 里的时间戳通常是毫秒级单调时间，如果两端用不同的起始点，差值会很大。
解决：联调时先用绝对时间（如 UTC 毫秒）做基准，或者确保两端都用get_monotonic_ms()并且启动时间接近。项目里如果有时间同步模块，确认它被正确初始化。
4.4 车辆列表膨胀：超时机制没生效
现象：RSU 运行一段时间后内存持续增长，日志里车辆数量只增不减。
原因：vehicle_list_update只做了插入没有做超时清理，或者超时时间设得太大。
解决：在车辆列表里加时间戳，每次更新时检查超过timeout_ms（通常 2000 到 3000 毫秒）的条目并删除。可以在主循环里加一个定时清理任务，每秒钟扫一次。
4.5 广播风暴：频率设太高导致信道拥塞
现象：联调时消息丢失率很高，日志里时有时无。
原因：BSM 广播频率设成了 10Hz 甚至更高，多个 OBU 同时发的时候信道占满了。
解决：测试阶段把 BSM 间隔调到 200ms 到 500ms，等基本功能验证完再逐步调回 100ms。如果项目支持动态调整，可以根据车辆密度自动降频。
5. 二次开发：改协议栈、换算法、加消息类型
5.1 替换风险判断算法
项目里的risk_judge_check通常是个简单实现，比如算个距离阈值。二次开发时最常改的就是这里。我的习惯是先把接口抽象出来：
// app/risk_judge.h typedef enum { RISK_NONE = 0, RISK_LOW, RISK_MEDIUM, RISK_HIGH } RiskLevel; RiskLevel risk_judge_check(const BsmMessage *bsm);然后在risk_judge.c里实现具体逻辑。如果要换成基于轨迹预测的算法，只需要改这个文件，不影响其他模块。验证方法是构造几组固定的 BSM 输入，看输出是否符合预期。项目里如果有单元测试框架，加几个用例跑一遍。
5.2 增加新的消息类型
J2735 定义了很多消息类型，项目里可能只实现了 BSM 和 SPaT。要加 RSI 或 TIM 消息，步骤是：
- 在
common/codec里加对应的编解码函数，参考已有的j2735_encode_bsm结构。 - 在
obu/app或rsu/app里加发送或接收任务。 - 在配置里加新的 PSID。
- 在 WSMP 层注册新的 PSID 处理回调。
关键是编解码函数要严格按 J2735 的 ASN.1 定义来，字段顺序和编码方式不能错。验证时先用固定数据编码再解码，看能否还原。
5.3 对接真实硬件
项目里的 HAL 层是模拟实现，对接真实硬件时改hal/下的文件。比如 GPS 从串口读 NMEA 语句，CAN 从 SocketCAN 读帧。改完后先用模拟数据验证业务逻辑，再切到真实硬件。常见问题是硬件数据频率和业务周期不匹配，比如 GPS 只有 1Hz，但 BSM 要 10Hz，中间需要做插值或保持。
5.4 一个实用技巧：用配置文件控制调试行为
二次开发时经常需要在不同行为之间切换，我的做法是在配置里加一个debug段：
{ "debug": { "log_level": "debug", "dump_bsm": true, "dump_spat": false, "simulation": true } }dump_bsm打开后把每条 BSM 的原始字节写到文件，方便和抓包对比。simulation控制是否用模拟数据。这样不用改代码就能切换调试模式，联调时省很多事。
从那以后我每次改协议栈相关代码，都强制先跑一遍单端编码解码测试，再跑两端联调，最后才上真实硬件。这个顺序帮我省了不少来回折腾的时间。希望帮到你。
本文还有配套的精品资源，点击获取
