车辆接口系统

相关源文件

• common/i2c.cc
• common/i2c.h
• selfdrive/car/__init__.py
• selfdrive/debug/check_freq.py
• selfdrive/debug/check_lag.py
• selfdrive/debug/check_timings.py
• selfdrive/test/test_onroad.py
• selfdrive/ui/qt/setup/reset.cc
• selfdrive/ui/qt/setup/reset.h
• tools/plotjuggler/layouts/controls_mismatch_debug.xml

汽车接口系统 (Car Interface System) 是一个抽象层，它使得 openpilot 能够支持广泛的汽车品牌和型号。它位于规划和控制系统与汽车硬件之间，将 openpilot 的通用控制指令翻译成特定于车辆的 CAN 消息，并将特定于车辆的传感器数据转换为 openpilot 规划系统可以使用的标准化格式。

有关 openpilot 如何规划和控制车辆运动的信息，请参阅 规划与控制。有关 openpilot 如何通过 Panda 设备与车辆通信的详细信息，请参阅 车辆通信。

系统架构

汽车接口系统由几个关键组件组成，它们协同工作，为不同的车辆平台提供一致的 API。

汽车接口架构概览

来源：selfdrive/test/test_onroad.py40-42

汽车接口架构展示了 openpilot 的规划和控制系统与汽车硬件之间的数据流。 card 守护进程是管理汽车接口类与系统其余部分之间通信的核心组件。

汽车抽象层

汽车抽象层为 openpilot 的其余部分与不同汽车品牌和型号交互提供了一个一致的接口。这是通过继承自通用接口的特定于汽车的类来实现的。

汽车抽象层

来源：selfdrive/test/test_onroad.py89-90

每个支持的车辆都有其 CarInterface 类的特定实现，该实现处理与该车辆通信的具体细节。这使得 openpilot 的其余部分能够以标准化的接口工作，而无需考虑使用的具体车辆。

汽车接口实现

每个车辆品牌和型号的汽车接口的实际实现组织在 selfdrive/car 目录下的一个分层结构中。

汽车接口实现结构

来源：selfdrive/car/__init__.py

每个汽车品牌（例如本田、丰田、现代等）在 selfdrive/car 目录中都有自己的子目录。在每个品牌的目录中，通常有四个主要的 Python 文件：

1. carstate.py - 负责解析 CAN 消息以确定车辆的当前状态。
2. carcontroller.py - 负责向车辆发送控制指令。
3. interface.py - 实现特定品牌的 CarInterface 类。
4. values.py - 包含特定于车辆的参数和指纹，用于识别特定型号。

数据流

汽车接口系统在 openpilot 和车辆之间处理双向数据。以下是数据流的详细说明：

汽车接口数据流

来源：selfdrive/test/test_onroad.py85-92

系统有两个主要数据路径：

1. 控制路径：控制指令由 openpilot 的规划系统生成，传递给汽车接口，翻译成特定于车辆的 CAN 消息，并发送到车辆。
2. 状态路径：车辆状态信息作为 CAN 消息接收，由汽车接口解析，并以标准化格式提供给 openpilot 的规划系统。

测试与验证

汽车接口系统包含全面的测试框架，以确保它能与不同的车辆型号正常工作。

汽车接口测试框架

来源：selfdrive/test/test_onroad.py115-177

测试方法包括：

1. 进程回放：针对记录的数据测试汽车接口，以确保行为一致性。
2. 汽车型号测试：专门测试每个支持的汽车型号的接口。
3. 路测：在真实驾驶条件下测试整个系统。

性能考量

汽车接口系统对性能有严格的要求，以确保安全且响应迅速的操作。

组件	预期 CPU 使用率	最大延迟	频率
card 守护进程	26.0%	不适用	不适用
carState	不适用	平均 2.5 倍	100Hz
carControl	不适用	平均 2.5 倍	100Hz

来源：selfdrive/test/test_onroad.py40-45 selfdrive/test/test_onroad.py85-92

card 守护进程是 openpilot 中 CPU 密集型组件之一，这反映了它在车辆控制中的关键作用。该系统旨在保持低且一致的延迟，以确保安全运行。

安全机制

汽车接口系统包含多项安全机制，以确保仅在安全的情况下才将控制指令发送到车辆。

安全检查流程

来源：tools/plotjuggler/layouts/controls_mismatch_debug.xml11-13 tools/plotjuggler/layouts/controls_mismatch_debug.xml26-28 tools/plotjuggler/layouts/controls_mismatch_debug.xml34 tools/plotjuggler/layouts/controls_mismatch_debug.xml41-42

安全检查包括：

1. 允许的控制：Panda 设备维护一个标志，指示是否可以向车辆发送控制指令。
2. 安全 RX 无效：表示收到的 CAN 消息无效或包含不一致的数据。
3. 安全 TX 阻塞：表示出于安全原因，正在阻止向车辆传输控制消息。
4. 驾驶员覆盖检测：系统检测驾驶员何时踩下油门或刹车踏板，并在这些情况下禁用自动控制。

特定于车辆的参数

每个支持的车辆都有一组特定的参数，定义了 openpilot 如何与其交互。

来源：selfdrive/test/test_onroad.py88-91

这些参数包括：

1. 汽车识别：用于识别特定车辆品牌和型号的参数。
2. 转向参数：与车辆转向系统相关的参数，包括延迟、比率和限制。
3. 物理参数：车辆的物理特性，例如轴距和轮胎刚度。
4. 安全参数：定义车辆安全配置的参数。

结论

汽车接口系统是 openpilot 的一个关键组成部分，它支持广泛的汽车品牌和型号。它为系统的其余部分与不同车辆交互提供了一个标准化的接口，负责将通用控制指令转换为特定于车辆的 CAN 消息，并确保安全检查得到正确执行。

该系统的模块化设计使得添加对新车型支持相对容易，而其全面的测试框架则确保了新添加的功能能够正确且安全地工作。