域描述

该 drivers 子目录包含直接与物理车辆传感器和对自动驾驶或外部模拟器系统至关重要的系统接口的节点和库。

中心页面

• ne_raptor_interface
• Spinnaker camera driver
• Spinnaker camera node
• ssc_interface design
• velodyne_driver
• velodyne_nodes
• vesc_interface

模型预测控制控制器

• 车辆界面高级设计
• 车辆界面设计
• 车辆接口现有技术
• 车辆接口故障分析
• 车辆接口参考实现

ne_raptor_interface

这是 ne_raptor_interface 包装的设计文件。

目的/用例

该软件包充当 New Eagle 的 Raptor DBW 软件和 Autoware.Auto 之间的消息转换器。

设计

这个包继承自 Vehicle 接口设计 ，因此，执行所有相同的任务，但特别是来自 raptor_dbw_msgs 堆栈的消息。

假设/已知限制

当前版本的 New Eagle 的 Raptor DBW 节点仅用于研发！

输入/输出/API

输入

• 当命令值应该改变时发送 Autoware 命令消息
• Raptor DBW 命令消息定期发送（建议每 20-100 毫秒）

From Autoware

• autoware_auto_control_msgs::msg::HighLevelControlCommand
• autoware_auto_vehicle_msgs::msg::VehicleControlCommand
• autoware_auto_control_msgs::msg::AckermannControlCommand（未经测试）。
• autoware_auto_vehicle_msgs::msg::VehicleStateCommand

To Raptor

• raptor_dbw_msgs::msg::AcceleratorPedalCmd
• raptor_dbw_msgs::msg::BrakeCmd
• raptor_dbw_msgs::msg::GearCmd
• raptor_dbw_msgs::msg::GlobalEnableCmd
• raptor_dbw_msgs::msg::MiscCmd
• raptor_dbw_msgs::msg::SteeringCmd

输出

• 定期接收 Raptor DBW 报告消息
• 一旦从 Raptor DBW 报告中编译了所有相关数据，就会传递 Autoware 报告消息

To Autoware

• autoware_auto_vehicle_msgs::msg::VehicleOdometry
• autoware_auto_vehicle_msgs::msg::VehicleStateReport
• autoware_auto_vehicle_msgs::msg::VehicleKinematicState

From Raptor

• raptor_dbw_msgs::msg::BrakeReport
• raptor_dbw_msgs::msg::GearReport
• raptor_dbw_msgs::msg::MiscReport
• raptor_dbw_msgs::msg::OtherActuatorsReport
• raptor_dbw_msgs::msg::SteeringReport
• raptor_dbw_msgs::msg::WheelSpeedReport

参数

• ecu_build_num ECU 构建#
• front_axle_to_cog 前轴到车辆重心的距离，以米为单位。
• rear_axle_to_cog 后轴到车辆重心的距离，以米为单位。
• steer_to_tire_ratio 转向角/汽车轮胎角比
• max_steer_angle 最大方向盘转角
• acceleration_limit m/s^2，零 = 无限制
• deceleration_limit m/s^2，零 = 无限制
• acceleration_positive_jerk_limit 米/秒^3
• deceleration_negative_jerk_limit 米/秒^3
• pub_period 消息发布周期，以毫秒为单位

内部工作/算法

• Autoware 命令消息在更改时发送，而 Raptor DBW 命令消息必须定期发送。

错误检测和处理

• 捕获无效的自治模式更改请求。
• 捕捉无效的速度变化
  • 在倒档时不能前进/在前进档时不能倒退。 在这种情况下，默认为命令速度 = 0。
• 将车轮角度命令限制在有效范围内
• 捕获无效的档位、雨刮器、前照灯和转向信号状态请求。
• 捕捉到矛盾的车轮速度

安全注意事项

参考/外部链接

• 新鹰：控制自动驾驶汽车的平台

未来的扩展/未实现的部分

• autoware_auto_vehicle_msgs::msg::RawControlCommand 未实施 - 命令单位未定义

Spinnaker camera driver

为什么我们实现了这个功能

我们需要能够从 GigE（以太网）摄像头（以及可能的其他摄像头）读取数据，并通过 ROS2 管道发布图像。 此驱动程序处理与 Spinnaker SDK（目前为 2.0.0.146-amd64 版本）的通信，以允许从其相机获取图像。

它是如何组织的

这个实现背后的主要思想是所有面向 SDK 的功能对用户都是隐藏的。 该库包装了 Spinnaker SDK 。

有许多包装器可以包装来自 Spinnaker SDK 的相应对象。 CameraWrapper 包装 CameraPtr 并处理图像订阅以及手动图像检索以及正确的相机创建、配置和销毁。

的实例 CameraWrapper 是在 中创建的 CameraListWrapper ，通过从 中获取它们来处理相机创建 Spinnaker::CameraList 。 它还可以处理摄像机和 Spinnaker::CameraList .

最后， SystemWrapper 处理 Spinnaker::SystemPtr .

如何使用

使用它应该很简单：

关于测试的一句话

这个包几乎没有经过测试，这是有原因的。 事实证明，为了测试目的，底层 SDK 很难扩展。 它将大部分引用计数指针包装在 Spinnaker::BasePtr<T> wrapper 中，不幸的是它在 type 上不是多态的 T ，即不能将 a 隐式转换 BasePtr<Derived> 为 a BasePtr<Base> 。 这使得模拟这些变得困难（如果不是不可能的话）。 除此之外，这些通常通过复制返回，这意味着每当我们在任何类中创建 Spinnaker SDK 的对象时，我们都会失去对正在创建的对象的控制并且不能轻易地模拟它。

另一种方法是在其中使用的所有 Spinnaker 类型上对我们的每个包装类进行模板化，但这会严重影响可读性，并且会更改类的设计，唯一的原因是这些类将在期间被它们的模拟替换测试，这似乎不是一个很好的设计决定。

Spinnaker camera node

目的/用例

我们需要一个节点，该节点将使用 Spinnaker 相机驱动程序连接到 Pointgrey/FLIR 相机并将其图像作为 ROS 2 消息发布。

设计

我们继承自并将 函数作为回调 rclcpp::Node 链接到 Spinnaker SDK 包装器。 publish_image

输入/输出/API

输入是从摄像头生成并由驱动程序读取的图像。 然后，驱动程序将使它们可用于该节点。

配置

通过参数配置节点。 这是对最重要部分的简短回顾。 有关详细信息，请参阅 spinnaker_camera_node.param.template.yaml 文件。

它可用于运行节点，如下所示：

配置摄像头

它支持两种配置方式：

• 提供将用于所有相机的相机设置的单个实例。
• 为每个摄像头提供一个摄像头设置实例。 这些数量必须与可用摄像机的数量相匹配。

配置发布者

如果 one_publisher_per_camera 设置为 true ，则发布者将与相机数量一样多，发布不同的主题。 如果设置为 false 具有单个主题的单个发布者将被重用。 然后可以根据它们的 frame_id .

相关问题

• #395 - 为 Spinnaker 驱动程序实现 ROS 2 节点

ssc_interface design

目的/用例

该软件包充当 AutonomouStuff 的 SSC 软件和 Autoware.Auto 之间的消息转换器。

设计

这个包继承自 Vehicle 接口设计 ，因此，执行所有相同的任务，但特别是来自 automotive_autonomy_msgs 堆栈的消息。

假设/已知限制

输入/输出/API

输入

来自 Autoware

• autoware_auto_vehicle_msgs::msg::VehicleControlCommand 命令速度和转向
• autoware_auto_control_msgs::msg::AckermannControlCommand 命令速度和转向（未经测试）
• 用于控制线控驱动模式、档位和转向信号的 autoware_auto_vehicle_msgs::msg::VehicleStateCommand

来自 SSC

• Automotive_platform_msgs::msg::GearFeedback
• Automotive_platform_msgs::msg::SteeringFeedback
• Automotive_platform_msgs::msg::VelocityAccelCov

输出

到汽车用品

• autoware_auto_vehicle_msgs::msg::VehicleOdometry
• autoware_auto_vehicle_msgs::msg::VehicleStateReport

至 SSC

• Automotive_platform_msgs::msg::GearCommand
• Automotive_platform_msgs::msg::SpeedMode
• Automotive_platform_msgs::msg::SteerMode
• Automotive_platform_msgs::msg::TurnSignalCommand

参数

• front_axle_to_cog 前轴到车辆重心的距离，以米为单位。
• rear_axle_to_cog 后轴到车辆重心的距离，以米为单位。

内部工作/算法

ssc_interface 采用内部状态机以符合 SSC 软件中的某些安全功能，并避免发送带有设置为真的启用标志的意外控制命令。 有问题的特定安全功能是要求在接受“启用”消息之前向每个系统发送“禁用”消息。 DbwStateMachine 类在内部持有一个状态，该状态取决于几个因素，默认为 DbwState::DISABLED 以避免意外向 SSC 发送启用的控制命令。 DbwStateMachine 的状态转换图如下所示：

• 从 DbwState::DISABLED 开始
• 如果用户请求启用 SSC，则转换到 DbwState::ENABLE_REQUESTED
• 一旦发送了初始控制命令和初始状态命令并将启用标志设置为 false，开始 true 在 DbwStateMachine::enabled() 中返回
• 一旦发送了启用标志设置为 true 的状态命令或控制命令，转换到 DbwState::ENABLE_SENT
  • 当处于 DbwState::ENABLE_SENT 状态时，去抖动由 SSC 返回的 DBW 启用状态值，以避免在 DBW 系统转换为启用时禁用
  • 如果 DBW 系统多次报告禁用（> debounce count），启用失败并转换回 DbwState::DISABLED
• 一旦 SSC 报告 DBW 系统已启用，转换到 DbwState::ENABLED
• 在 DbwState::ENABLED 中时，如果用户请求它或 SSC 从 DBW 系统报告它，则立即转换到 DbwState::DISABLED

错误检测和处理

ssc_interface 当前检测到无效的档位和转向信号命令，以及需要使用来自 的 SafetyStateMachine 的参数 vehicle_interface 。

安全注意事项

参考/外部链接

• 速度和转向控制软件

未来的扩展/未实现的部分

velodyne_driver

为什么我们实现了这个功能

velodyne 驱动程序本身从根本上将数据包转换为点。 与 UDP 套接字的通信、错误处理和状态转换由不同的类处理，即 autoware::drivers::udp_driver::UdpDriverNode。

最后，注意尽可能优化驱动程序的速度。 在最紧凑的循环中避免了诸如取模和除法之类的昂贵操作，并且尽可能多的工作被委派给初始化计算，并在运行时通过查找表使用。 此外，在各种循环中使用休眠来释放可能不需要的硬件资源。

修改

应用的一项修改是，除了标准值（例如空间坐标和强度）之外，我们还保留了来自传感器本身的一些顺序信息。

具体来说， id 被跟踪，它将点云的点合并为 16 个点块，这些点组成了一个火焰图案，或者可以被认为是一条射线，在这种情况下，16 是 Velodyne 特定型号中的激光器数量使用了激光雷达。 此信息用于下游，尤其是在 ray_ground_filter .

对驱动程序 API 的另一个修改是在接收到完整的点云之前可以看到或消耗点。 这允许在点云进入时进行下游计算（例如过滤、地面分割），以最大限度地减少系统的整体延迟。 在这个用例中，一个特殊的 id , END_OF_SCAN_ID = 0xFFFF 用于表示一个点云在哪里结束，另一个在哪里开始。 为了在处理这些点流的系统中保持一致性， 必须 将界定两个点云的点推到下游。

上述点流在以下方面与 ROS/DDS 主题不同：

• 点流是进程内的，这意味着它们在同一进程的线程之间发送
• 点流通过无等待的单生产者单消费者环形缓冲区而不是 tcp/udp 进行通信
• 已定义接口定义（例如参见 velodyne/point_stream.h ）以允许不同的组件从中间点流或直接从另一个模块的点流中读取（例如直接从驱动程序到射线地面过滤器）
• 点流可以通过将 PointCloud2 信息累积到消息的数据向量中来转换为消息，直到 END_OF_SCAN_ID 被接收
• PointCloud2 通过在收到消息时扫描消息并将每个点推送到下游，可以将消息转换为点流

使用点流的另一个设计目标是最小化 ROS/DDS 层的暴露。 如果改为使用 DDS 主题在线程之间进行通信，则会有大量信息以非常高的速率在 DDS 中传播，即使其他组件不需要这些信息。

性能表征

时间

对任意一个数据包进行操作并生成任意一个点的运行时间为 O(1) 。 由于驱动程序必须等待来自传感器的数据包，并且由于完整激光扫描中的数据包数量是用户定义的，因此运行时间是 O(n) 点云的大小。

空间

Velodyne 驱动程序的空间复杂度为 O(1) . 它由预先分配的查找表支配。

模块 IO（输入/输出）和常量

输入：

• 配置参数 Vlp16Translator

velodyne 驱动程序本身通常将点向量转换为消息类型。

参考

• velodyne 参考文档
• ROS1 的参考实现

velodyne_nodes

目的/用例

我们要求 Velodyne 驱动程序能够与基于 ROS 的系统交互。

设计

这些节点使用 UdpDriver 从套接字接收数据包，然后使用 Vlp16Translator 将数据包解析为 sensor_msgs::msg::PointCloud2。

这些节点的目的是将来自 VLP16 HiRes 传感器的 Udp 数据包转换为 ROS 2 消息。

假设/已知限制

假设来自 Velodyne 传感器的某个 UDP 端口上的输入。

对于 VelodyneCloudNode，假设 PointCloud2 消息至少大于 velodyne_driver::Vlp16Translator::POINT_BLOCK_CAPACITY，即 512。

输入/输出/API

输入：

• 来自 VLP-16 LiDAR 传感器的 UDP 数据包

输出：

• PointCloud2 消息

安全注意事项

这些节点继承了 UDP 驱动程序、Node 和 Vlp16Translator 中固有的所有安全缺陷和功能。

未来的扩展/未实现的部分

这个节点最终应该有健康主题发布者和命令订阅者用于融合协调。

相关问题

• #4 - 实现 velodyne 驱动程序
• #1309 - 更新驱动程序以更改 ros udp 驱动程序 1.0

车辆界面高级设计

车辆接口将通用自动驾驶软件堆栈与特定车辆连接。 这包括 向车辆硬件传输命令，以及 从 车辆平台 接收报告或传感器数据。

在定义标准接口之前，每种不同类型的车辆都需要稍微不同的车辆接口。

用例

本节定义了通用车辆接口可能遇到的通用用例和设置。

车辆界面应大致执行以下操作：

1. 充当驾驶员座位上的人的替代品
2. 提供对硬件的低级访问
3. 防止不安全的动作、组合或动作序列
4. 促进自动驾驶软件堆栈的轻松开发
5. 允许物理驱动程序优先控制

取代人类驾驶员的物理存在

为了启动车辆并接收适当地安全启动车辆所需的信息，车辆界面应该取代人类驾驶员。

预测、规划、路由等其他方面超出了范围。

致动一般是指控制车辆的转向、油门、制动、档位和指示灯。

接收信息一般是指在驾驶员仪表盘上发现的信息，例如车速、油量信息，以及指示灯、档位的当前状态等。

提供底层硬件访问

某些车辆平台可能有一组更精细的传感器，这些传感器不会直接暴露给人类驾驶员，例如单独的车轮里程计或前置雷达。 来自这些传感器的信号还应该暴露给更广泛的自动驾驶系统堆栈。

防止不安全的（一系列）动作

车辆界面应防止已知不安全或对车辆造成损害的行为。

这可以包括快速启动制动器、油门或转向，以及在车辆具有不可忽略的速度时换档停车。

促进 ADAS 开发

车辆接口应提供具有不同粒度级别的接口。 应该提供一个低粒度的接口来从用户那里抽象出大量的控制和边缘情况。 应提供高粒度接口，以将硬件-软件接口的全部功能公开给软件堆栈。

虽然“容易开发”的定义不明确，但近似值是最小化输入自由度的数量。

更具体地说，可以通过支持以下用例来促进开发：

1. 使用游戏手柄控制车辆平台（最低限度地测试车辆接口和线控接口）
2. 使用了解某些车辆细节的组合纵向和横向控制器/规划器来控制车辆，而无需直接控制换档
3. 使用具有解耦速度（纵向）控制的几何路径规划器，对车辆平台知之甚少

此外，根据车辆接口中存在的逻辑数量，接口与模拟器兼容可能是有用的，以便可以适当地测试和练习接口逻辑。

最后，使支持多种硬件-软件通信机制成为可能也将简化开发。

允许物理驱动程序优先控制

如果车辆接口是车辆平台控制的唯一仲裁者，则车辆接口应优先允许车辆的物理驱动。 在开发的情况下，应该始终如此。 在生产车辆中，永远不允许物理干预可能是合适的。

许多车辆平台可能会通过线控接口的操作方式隐含地允许这样做。

要求

上面的用例可以分解为需求：

1. 更换物理驱动程序
   1. 提供一种直接控制车辆以下方面的方法：
      1. 风门
      2. 制动
      3. 操舵
      4. 齿轮状态
      5. 大灯
      6. 转向灯
      7. 危险灯
      8. 喇叭
      9. 雨刷
   2. 提供一种从车辆平台报告以下信息的方法：
      1. 速度
      2. 转向角
      3. 齿轮状态
      4. 大灯状态
      5. 转向灯状态
      6. 危险灯状态
      7. 喇叭
      8. 雨刮器状态
   3. 假设车辆的控制在命令之间具有零阶保持
2. 提供底层硬件访问
   1. 报告其他传感器信息，示例包括：
      • 雷达
      • IMU
      • 全球定位系统
      • 超声波
   2. 提供额外的 API 以进行额外的控制（例如单个车轮扭矩）
3. 防止不安全的行为
   1. 防止控制信号中的高频振荡
   2. 防止以非零速度换入驻车档
   3. 在车厢和物品未固定时防止激活 ADAS 功能
   4. 确保在雨刮器运行时大灯处于活动状态（加利福尼亚州法律）
   5. 此功能应该是可选的，因为它与提供对车辆平台的低级访问背道而驰
4. 促进 ADAS 开发
   1. 提供高级接口来控制速度
   2. 提供高级接口来控制路径曲率
   3. 允许不同的通信机制
      1. 连接模拟器
5. 允许物理驱动程序优先控制
   1. 如果检测到手动控制，软件应阻止对车辆平台的所有控制命令

机制

为了满足车辆接口的要求，定义了以下组件（大致对应于面向对象编程中的类）：

1. 控制消息
   1. RawControlCommand
   2. VehicleControlCommand
   3. HighLevelControlCommand
2. 其他界面消息
   1. VehicleStateCommand
   2. VehicleOdometry
   3. VehicleStateReport
3. 车载平台硬件通讯机制
4. 车辆专用界面
5. 安全状态机
6. 车辆接口
7. 低通滤波器
8. 控制器

这些组件将在下面进一步详细描述。 所有组件都可以按照以下 UML 图指定的方式组合：

Vehicle Interface Architecture

控制消息

车辆接口的一个基本要求是操纵车辆的运动状态。 因此，需要一个定义所请求运动学状态的接口。

为车辆控制定义了多种消息类型。 这是因为没有一种消息类型可以适当地涵盖所需的用例（易于开发，防止不安全的操作），同时尽可能保持具体和明确。

对于每种消息类型，纵向和横向控制动作都组合成一个类型，并且不使用预定义的消息定义。 前者的目的是消除车辆接口内时间同步或消息对齐的需要。 实施后者是为了最小化通信消息的大小并消除歧义。

在所有情况下，这些消息都旨在以大约 100 Hz 的高频率发布。

原始控制命令

该消息类型定义如下：

这种类型旨在用于需要直接控制车辆硬件的情况。 因此，不对单位做出任何假设。 系统集成商有责任确保所使用的值适用于车辆平台。

车辆控制命令

该消息类型定义如下：

消息语义表示对车辆的瞬时控制（即手放在方向盘上，脚放在踏板上）。 这种类型旨在用作具有代表性的力量的中间地带，暴露直接的车轮角度，但抽象出一些制动/节流细节。

使用这种类型作为主要输入的车辆接口预计至少包括安全状态机。

保留后轮角度，以备将来可能扩展到 Quadrasteer 或后转向平台。

高级控制命令

该消息类型定义如下：

这种类型旨在仅在需要简单控制时用作接口，从而抽象出对车辆的更直接控制。

使用这种类型作为主要输入的车辆接口预计至少包括安全状态机和控制器。

其他界面消息

为车辆接口定义了其他接口类型。

车辆状态命令

该消息类型定义如下：

该消息表示车辆与驾驶相关的所有其他方面的低频控制。

此消息旨在以较低的未指定速率发布，例如 1-10 Hz。

车辆里程计

该消息类型定义如下：

此消息表示来自车辆平台的通用传感信息，需要估计车辆的运动学状态。

该数据预计是高频的，并且可以被视为“尽力而为”。

车辆状态报告

该消息类型定义如下：

该消息表示车辆平台的非控制相关状态。

它旨在用于更新车辆界面和行为规划器中的状态机。

预计该数据的频率适中，可以视为“尽力而为”。

车载平台硬件通讯机制

每个车辆平台都有一些通信机制，通过该机制可以传输命令和接收报告。

大多数车辆平台使用 CAN。 支持模拟器可能需要使用自定义接口或其他通信机制，例如 ROS 1/2 发布者或 websocket。

车辆专用界面

每个车辆平台可能具有不同的控制特性，例如车辆特定的制动器或油门表。

该组件的目的是将通用的、与平台无关的命令转换为特定于车辆的数据，并将这些命令传输到车辆平台本身。

同样，该组件必须从平台接收报告，并将此信息转换为与车辆无关的消息。

由于通信机制可能因平台而异，因此该组件应封装平台使用的任何通信机制。

安全状态机

安全状态机维护一个内部状态，该状态最低限度地代表车辆平台。 然后使用该状态机将可能不兼容的命令集转换为一致的命令集。

具体来说，这个安全状态机的状态应该与 VehicleStateReport 类型中表示的大致相同（它可能是子集或超集）。

该状态机应拒绝的一些命令组合的示例是要求 3.2、3.3 和 3.4。

车辆接口

车辆接口是一个更高级别的组件，它通过 ROS 2 的 IPC 机制提供与更大的 ADAS 堆栈的交互点。 此处列出的所有其他组件都包含在此组件中。

低通滤波器

通用低通滤波器或任何等效滤波器（例如 Butterworth、Chebyshev 等）应可选用于从控制信号中去除高频噪声。

控制器

如果开发人员希望通过速度而不是加速度来控制车辆，控制器应该是可选的。 这可以是任何简单的参考跟踪控制器，例如 PID 控制器。

相关问题

• #230：初始导出

车辆界面设计

目的/用例

自动驾驶软件堆栈的主要外部接口是感知传感器和车辆平台本身。

因此，需要一个允许自动驾驶软件堆栈和车辆平台之间通信的节点来控制车辆并报告车辆的状态。

设计

总的来说，车辆界面执行以下操作：

1. 确保发送到车辆的命令是安全的
2. 向车辆发送命令
3. 从车辆接收信息
4. 支持多种车载平台/通讯机制

为了支持这些用例，设计了以下架构：

Vehicle interface architecture

架构中的以下组件是车辆接口包的直接关注点：

1. 安全状态机
2. 平台界面
3. 车辆接口节点

安全状态机

安全状态机确保发送到车辆的命令安全且一致。

所有打算在运行时使用的方法都被标记 noexcept 为这里没有任何东西会失败。

因此，警告是通过单独的方法（而不是异常）报告的。 基本原理是状态机应该始终能够使命令安全，这意味着始终会生成命令。 相比之下，抛出异常会破坏这条路径（生成命令），需要一条备用路径来报告警告。

假设/已知限制

该组件对 API 强制执行的内容没有任何假设。 该组件的工作是强制执行假设。

输入/输出/API

建议的 API 可以在 这里看到 。

内部工作/算法

安全状态机预期会出现以下行为：

1. 如果车辆的速度非零，则应移除驻车、倒车和行驶之间的任何换档
2. 如果雨刮器处于活动状态，大灯应处于活动状态
3. 命令应限制在预先指定的范围内
4. 如果原始值和限定值之间存在较大误差，则应发出警告
5. 验证控制命令中的高频分量很小应该发生在这里； 如果存在高频分量，则应发出警告
6. 如果状态命令在特定时间段内未导致报告状态发生变化，则应发出警告

错误检测和处理

在有问题的情况下（上一节中的第 4、5 和 6 点），应提出警告或例外。

无论是使用警告还是异常，都应该是可参数化的。

平台界面

平台接口允许从车辆平台发送和接收数据。

假设/已知限制

假设平台接口封装了与车辆的通信机制，以及翻译平台特定消息或命令所需的任何库或实用程序。

任何基于 DBC 文件的代码生成都被认为超出了本设计的范围。 这种自动生成的代码可以用作平台接口实现中的库。

应报告与车辆平台通信的任何故障，因为它被视为严重错误。

输入/输出/API

建议的 API 可以在 这里看到 。

虚拟接口使用返回码，因为不可能强制在错误时抛出异常，而缺少返回语句通常是编译错误。

内部工作/算法

这主要是一个接口。 当车辆不处于自主模式时，有一些逻辑可以防止发送命令。

错误检测和处理

平台接口的主要故障模式是向车辆平台发送数据或从车辆平台接收数据失败。

虽然实现者可能在他们的平台接口实现中包含一些重试机制，但最终应该 VehicleInterfaceNode 通过返回码或抛出的异常向平台报告失败。

在这些情况下，与接口的通信故障被视为严重错误，应采取一些安全措施。

车辆接口节点

车辆接口节点包含与车辆通信所需的所有组件。

假设/已知限制

通常假设车辆接口节点的实例将作为单独包中的子类实现。

这种模式优于工厂方法，以提高可扩展性并确保“物有所值”，这意味着开发人员不必依赖其他接口实现即可使用特定接口。

输入/输出/API

建议的 API 可以在 这里看到 。

作为一个节点，输入是：

1. 以下之一：
   • VehicleControlCommand （不赞成使用 AckermanControlCommand ）
   • AckermannControlCommand
   • RawControlCommand
   • HighLevelControlCommand
2. VehicleStateCommand

此外，每个车辆接口或特定车辆可以支持其他车辆接口或特定车辆不支持的特征。 为了适应这种情况，必须将 autoware::drivers::vehicle_interface::ViFeature 类型的功能列表传递给 VehicleInterfaceNode 类。 向此列表添加功能表示线控驱动或模拟器接口支持此功能，但这样做不会自动启用该功能。 要启用一项功能，还必须 features 在配置节点时将其添加到参数中。 向 features 参数添加功能表明它受正在使用的特定车辆的支持。 必须向 VehicleInterfaceNode 子类和 features 要启用该功能的发布者和订阅者的参数。 有关可用功能，请参阅 ViFeature 枚举。

然后输出是：

1. VehicleOdometry
2. VehicleStateReport
3. 基于车辆平台的附加传感器消息

内部工作/算法

车辆接口节点本身的逻辑相对较少。 它主要将逻辑卸载到本文档和架构中的其他组件。

错误检测和处理

处理各种故障模式。 这些主要由安全状态机和（可选）在控制命令上使用低通滤波器封装。

在节点级别实现了两个额外的错误处理机制：

1. 旧数据被忽略
2. 如果没有来自 ADAS 堆栈的命令，车辆界面将平稳停止并亮起危险灯

有关各种错误情况和缓解策略的更多详细信息，请参阅 车辆接口故障分析 。

安全注意事项

平台接口直接与车辆平台交互。 这是一个可能不使用 DDS 的外部通信渠道。

这里可能需要额外的安全机制。

参考/外部链接

• 车辆接口现有技术
• 车辆界面高级设计
• 车辆接口故障分析

未来的扩展/未实现的部分

以下内容尚未实施：

1. 速度控制

相关问题

• #230：初始导出

车辆接口现有技术

本文档旨在回顾车辆接口实现和组件实现方面的现有技术。

Autoware.Auto

Autoware.Auto 没有完整的车辆界面。 一些讨论和文档已经开始。

用例讨论

• AutowareAuto #85

DBW 接口支持：

• 数据速度
• 新鹰
• PAC模组
• ZMP 混合动力汽车
• YMC

接口：

• 纵
  • 速度
  • 最大/最小加速度
• 侧
  • 角加速度
  • 期望/最大曲率
• 其他
  • 换档
  • 转弯信号

杂项话语帖子

• 社区调查
  • 无内容
• 会议 5
  • 无内容
• 会议 4
  • 提倡分层架构支持多种用例
  • 关于输入类型的一些讨论
  • 讨论用例的决议
• 会议 2
  • 专注于CAN
  • 建议使用 帧消息 ，支持 SocketCAN桥 和 Kvaser接口
    • 社论：使用此框架消息可以作为车辆接口插件的可选后端

车辆接口参考实现

• 车辆接口架构
• 与设计基本一致
• 但也有“超时回退行为”

阿波罗

Apollo 有一个集中的车辆接口。 它们的主要通信机制似乎是 CAN。 他们使用工厂模式支持各种车辆。

他们的车辆界面的主要输入是 ControlCmd ，它有很多字段。

他们车辆界面的主要输出是 Chassis 和 ChassisDetail 。

总线

• 阿波罗巴士
• CanbusComponent 接收控制命令，发布底盘状态
• 控制器嵌入在canbus中
  • 跟踪延迟，并忽略过早到达的消息
• 通过工厂模式支持不同的车辆
• 车辆对象用于实例化车辆控制器
  • 车辆控制器本质上是一个API来 控制 车辆
  • 刹车、转向、油门、启用/禁用自主模式、档位、喇叭、信号、刹车、仅转向、仅速度
• 具有仅控制纵向或仅控制横向的可选功能
• 似乎有自动生成的“协议”代码

CAN客户端

关联

• 基于定时器的传感器驱动程序
• 分开的发送者和接收者
  • 发件人具有非常高的优先级集 ( 99 )
• CAN客户端是一个接口类
  • 他们对不同的 CAN 卡有不同的客户端（Fake、Esd、Hermes、Socket）
  • 每种类型都是通过工厂模式构造的
  • 发送 API 是 std::vector<CanFrame> * const, int32_t * const)
    • 与接收相同

Autoware.ai

Autoware.ai 没有车辆界面。 有分散的包支持各种线控接口。 开始了一些关于整体设计的讨论。

设计工作

• #1541 中的 Autoware 讨论
• 设计
  • 具体节点 wrapping VehicleAbstraction ，它包含以下内容：
    • CanDriver接口
    • CanMsg 父类
• 讨论主要围绕 CAN 消息类的实现
• 还讨论了是否使用 将 can_msg/Frame CAN 驱动程序与车辆接口分开（并在两者之间使用 DDS）

车载插座

• 车辆插座
• 分离发送者和接收者
• 发件人
  • 旋转 ROS 以接收 VehicleCmd 消息，并将其放入某个全局结构中
  • 创建一个线程，该线程创建一个将纯文本数据写入 TCP 端口的线程
• 接收者
  • 有出版商 CANInfo 类型
  • 创建一个 pthread，它产生一个线程来侦听 TCP 端口并反序列化 CAN 数据

YMC

• YMC
• 包装库的 ROS 节点
• 有一些额外的逻辑来处理键盘输入
• 具有处理游戏手柄/操纵杆输入的逻辑
• 可能有一个自定义 CAN 发送器

克瓦瑟

• 克瓦泽
• 转换器只是监听 CANIfo 主题，反序列化，并打印内容
• CanDraw 做同样的事情，但也会发布转向方向的线列表
• 监听器通过 Kvaser CanLib 监听，并发布 CANInfo 消息

mqtt 套接字

• mqtt_socket
• 分离发送者和接收者
• 发件人以纯文本字符串形式发送以下内容：
  • CANInfo
  • PoseStamped
  • TwistStamped
  • 细绳
• Receiver 只处理逗号分隔的字符串

AS (AutonomouStuff) 节点

• 作为
• 普通翻译节点，订阅，然后发布
• 使用大量消息过滤器
• 内置了一些紧急停止功能

Comma.ai 的 OpenPilot

• 开放式飞行员
• 他们使用 Panda ODB 作为 DBW
• 对FlexRay 的传入支持
• 系统架构 的一般描述
• 使用 ZeroMQ 进行 IPC

能够

• openpilot CAN
• 根据 DBC 定义自动生成一些代码
• 大量车辆特定的解析代码

板子

• 板子
• 在启动时执行 VIN 检查（通过 ODB 代码）
• 可通过 USB 连接到 CAN
• 健康数据：自主开启、“气体拦截器”开启、GPS、CAN 发送错误、CAN“fwd”错误、GMLAN 错误、硬件类型和 USB 电源模式

车

• 敞篷车

社论

整体架构

所有实现和设计中的共同主题是：

1. 支持不同的车辆平台
2. 支持不同的通信机制
3. 使用可以处理从 ADAS 堆栈到车辆平台的通信的通用组件
4. 没有一个实现在接口中添加太多额外的逻辑

前三点封装在 VehicleInterfaceNode 和 VehicleInterface 抽象类中。

也可以说，可以为不同的通信机制开发通用的发送者/接收者类。 然后，特定平台接口可以使用最合适的通信机制（大概是固定的）。

因此，最好不要尝试在通信级别上模块化车辆接口，而是在平台级别上进行模块化。

对于后一点，可以说，由于我们支持联合堆栈而不是单片堆栈，因此在接口中具有额外的逻辑是合适的。

从安全的角度来看，拥有一些“安全”逻辑以确保车辆界面严格假设所有其他组件都正常工作也是有意义的。

车辆通讯接口

不同的车辆平台使用不同的通信接口。 即使在特定的接口类型（即 CAN）中，也有许多不同的实现。

这些接口包括：

1. 能够
   1. 套接字CAN
   2. 克瓦瑟
2. 数据速度
3. 新鹰
4. PAC模组
5. ZMP 混合动力汽车
6. YMC
7. 静电放电
8. 爱马仕
9. 数据库
10. 弹性射线

在短期内，支持 CAN 可能是最有意义的。 进一步的发展将取决于客户的需求。

接口

大多数接口（例如 Apollo、OpenPilot，甚至是较小程度的 Autoware.AI）都将大量命令包含在一条消息中。

总的来说，净表示似乎是相同的。

似乎没有其他接口直接支持多种可能的输入类型，这是联合与单片模型的结果。

相关问题

• #4942：回顾车辆界面设计中的现有技术和相关技术
• #4770：查看 1.0.0 版本的新设计文章

车辆接口故障分析

本文档的目的是确定车辆接口组件可能发生故障的方式，并确定这些故障方式的缓解策略。

应用逻辑

车辆接口的目的是对控制输入执行输入验证，将结果传递给车辆，并报告来自车辆的信息。

此应用程序的一般过程如下：

1. 接收数据
2. 超时->（可选）危险灯并减速
3. （可选）通过控制器计算加速/转向命令
4. （可选）控件上的低通滤波器
5. 读取状态命令
6. （可选）通过状态机传递命令
7. 向车辆发送最终命令
8. 从车辆读取信息
9. 发布从车辆读取的信息
10. （可选）更新状态机

失败方式

对于每个步骤，已确定以下故障模式：

1. 接收数据
   1. 输入数据错误
   2. DDS/ADAS 堆栈中的数据未及时到达
   3. 数据频率高
   4. 数据可能乱序
   5. 数据超出范围
2. 超时->（可选）危险灯并减速
3. （可选）通过控制器计算加速/转向命令
4. （可选）控件上的低通滤波器
   1. 实现错误（状态机、过滤器、控制器等）
   2. 过滤器可能无法正常工作
5. 读取状态命令
   1. 没有可用的状态命令（通过读取）
6. （可选）通过状态机传递命令
   1. 发送冲突的命令
7. 向车辆发送最终命令
   1. 在自主控制期间可能发生手动控制
   2. 车辆可能无法确认命令
   3. 车辆可能无法执行命令
8. 从车辆读取信息
   1. 来自车辆平台的数据未及时到达
   2. 来自车辆的传感器数据可能错误或损坏
9. （可选）更新状态机
   1. 状态机未更新，或错过更新（将其置于不一致状态）

缓解措施

对于每种故障模式，已确定以下缓解措施（或为什么不需要缓解措施的理由）：

1. 输入数据错误
   1. 通过状态机验证输入，通过安全功能确保系统完整性
2. DDS/ADAS 堆栈中的数据未及时到达
   1. 安全停止数据超时
3. 数据频率高
   1. 低通滤波器
4. 数据可能乱序
   1. 跟踪最新时间戳，忽略（并警告）早于最新时间戳的数据
5. 数据超出范围
   1. 钳位值，使用配置的限制
   2. 如果数据超出范围，发出警告； 可能是用户错误或其他问题
6. 实现错误（状态机、过滤器、控制器等）
   1. 全面测试实现
7. 过滤器可能无法正常工作
   1. 可以对输出做额外的验证； FFT，跟踪衍生品，或跟踪方差
8. 没有可用的状态命令（通过读取）
   1. 这不是错误：无事可做
9. 发送冲突的命令
   1. 状态机使命令一致
10. 在自主控制期间可能发生手动控制
    1. 如果车辆未处于自主模式，甚至不要尝试发送命令
11. 车辆可能无法确认命令
    1. 如果通信机制支持确认，则在某个超时内未确认命令时发出警告
12. 车辆可能无法执行命令
    1. 可以添加额外的状态 SafetyStateMachine ，可能需要保留一些历史，因为更新可能会滞后一点
13. 车辆平台数据未及时到达
    1. 取决于平台
    2. 这可能是一个严重错误（例如 DBW 已关闭）
    3. 绝对应该通知开发人员，并且平台应该执行超时行为（但可能无法完全降低风险）
14. 来自车辆的传感器数据可能错误或损坏
    1. 确保堆栈中其他位置的所有组件都验证其输入； 接口的实现者应该使用特定领域的知识来验证
15. 状态机未更新，或错过更新（将其置于不一致状态）
    1. 最小化状态机中的路径长度——确保状态机依赖于最后的观察而不是观察的历史

概括

作为故障分析的结果提出的缓解措施可以使用以下架构组件进行编码：

1. 低通滤波器
2. 安全状态机
   1. 数据钳位可能发生在这里
   2. 验证数据是低频的可以在这里发生
   3. 此处可将控制数据钳制在安全范围内
   4. 此处可能会出现控制数据严重超出范围时的警告
   5. 状态机应具有较短的路径长度
   6. 如果在被命令后没有发生状态转换（在某个超时内），则应发出警告
   7. 控制和状态命令的组合在这里应该保持一致
3. 平台界面
   1. 如果车辆未处于自主模式，则不应发送命令
   2. 如果数据未及时从平台到达，则应发出警告或错误
   3. 如果车辆通信机制支持确认，如果没有及时收到确认，则应发出警告

整体实施应强制执行以下行为：

1. 超时安全停止
2. 忽略旧数据

相关问题

• #4944：为车辆接口添加故障分析文档
• #4770：查看 1.0.0 版本的新设计文章

车辆接口参考实现

本文档定义了车辆接口组件的参考实现。 至少满足本文档中定义的输入、输出和行为的软件组件（即库、可执行文件、可执行文件集或软件黑盒）应能够与任何足够兼容的 Autoware 一起运行。自动衍生自动驾驶堆。

介绍

车辆接口是自动驾驶堆栈中最低点的软件组件。 它将堆栈中的命令转换为物理车辆上的驱动。 该组件的职责是充当从软件到硬件的转换器。

范围

本文档列出了车辆接口的最小输入、输出和行为集。

特别是，本文档定义了输入和输出的消息类型，以及它们定义背后的基本原理。 行为是根据预期结果定义的，并且类似地概述了基本原理。

符合这些输入、输出和行为的实现将能够与任何足够符合 Autoware.Auto 的自动驾驶堆栈一起运行。

附加行为和输出可用于车辆接口实现。 这些应适当记录。 如果使用了额外的输入，那么在不包含额外输入的情况下，本文档中概述的最小行为应该仍然是可能的。

参考实现

本节概述了最小车辆接口实现所需的输入、输出和行为

输入

车辆接口预计需要两个输入：

• 车辆控制命令消息：用于控制车辆轨迹的致动命令
• 车辆状态命令消息：车辆其余状态的辅助命令

车辆控制命令消息

车辆控制命令消息具有以下形式：

此消息类型旨在为油门踏板和制动踏板上的脚以及方向盘上的双手提供代理，同时还为控制器开发人员提供方便的表示。

这些车轮角度是逆时针正的，其中 0 对应于中性或前向方向。

默认值 ：所有字段的默认值为 0

基本原理 ：提供时间戳字段是因为应生成控制命令以响应车辆运动状态的输入。 保留触发数据的时间应该有助于诊断和可追溯性。

基本原理 ：提供单个加速度场是因为控制器通常会为刚体规划纵向加速度和转向角。 为了简化控制器开发，制动被包含在这个单一命令中，并且因为通常不希望同时踩下制动器和加速器。

基本原理 ：提供车轮转向角，因为它允许控制器只需要车辆平台的简化视图，例如知道轴距长度。 根据线控接口的实现，产生给定的车轮角度可能需要了解方向盘角度与车轮角度之间的映射关系。

基本原理 ：还提供后轮角度以支持后驱动车辆，例如叉车。

理由 : 没有提供框架，因为它暗示它是固定在车架上的。

有关消息的更多详细信息，请参阅包中的正式消息定义 autoware_auto_vehicle_msgs 。 虽然为方便起见，此处重复此消息及其基本原理，但应将消息包视为事实来源。

车辆状态命令消息

车辆状态命令消息具有以下形式：

该消息旨在控制车辆状态的其余部分，例如那些不需要最小无碰撞驾驶的状态。

默认值 ：所有字段的默认值应为零。

基本原理 ：危险信号灯取代了左/右信号，因此是专有状态

理由 ：可能需要清洁以确保安装在挡风玻璃后面的传感器能​​够正常运行

理由 ：可能需要喇叭来向其他司机发出信号

基本原理 ：自主是一个标志，因为这是一条命令消息：true 请求转换为自主，false 请求脱离手动。

基本原理 ：虽然其他领域（例如前灯、雨刷、齿轮等）可能存在其他状态，但此消息仅规定了大多数或所有车辆可以满足的最小状态集。

有关消息的更多详细信息，请参阅包中的正式消息定义 autoware_auto_vehicle_msgs 。 虽然为方便起见，此处重复此消息及其基本原理，但应将消息包视为事实来源。

输出

车辆接口预计会产生两个输出：

• 车辆里程计消息：报告运动学信息
• 车辆状态报告消息：报告有关车辆非运动状态的信息

如果车辆有其他可用信息，例如通过内置 RADAR、GPS 或 IMU，则应在适当类型的单独主题上输出此信息。

车辆里程计信息

车辆里程计消息具有以下形式：

该消息报告车辆自身的运动学状态。 此消息的预期用例可能是初始条件的运动规划或航位推算。

默认值 ：此消息的默认值在所有字段中都应为 0。

基本原理 ：此消息与车辆状态报告是分开的，因为它们通常用于不同的用例（例如行为规划与航位推算）

基本原理 ：车辆应配备提供速度和转向角的编码器。 加速和其他字段可能并非在所有车辆平台上都可用。

基本原理 ：这里需要盖章，因为这是及时的信息。 从这个意义上说，车辆接口充当传感器驱动程序。

理由 : 未提供车架 ID，因为这些车架被假定为固定在车架上，并且航向信息不可用。

有关消息的更多详细信息，请参阅包中的正式消息定义 autoware_auto_vehicle_msgs 。 虽然为方便起见，此处重复此消息及其基本原理，但应将消息包视为事实来源。

车辆状态报告消息

车辆状态报告消息具有以下形式：

默认值 ：不适用。 所有字段都应可由车辆界面填充。

基本原理 ：提供了离散的燃料范围，因为可能不需要更精细的粒度。

基本原理 ：提供了一个简单的状态机来确保在有意手动和两种无意处于手动模式的模式之间消除歧义：由于未满足先决条件，或者由于自动驾驶堆栈的某些故障。

有关消息的更多详细信息，请参阅包中的正式消息定义 autoware_auto_vehicle_msgs 。 虽然为方便起见，此处重复此消息及其基本原理，但应将消息包视为事实来源。

行为

兼容的车辆接口实现至少需要以下行为：

1. 命令映射：将控制命令映射到车辆的逻辑输入
2. 零阶保持：在收到命令消息之间命令一个恒定的驱动命令
3. 状态报告：定期报告车辆的当前状态

1. 不安全的命令拒绝：拒绝不安全的命令或命令序列
2. 超时回退行为：如果没有收到命令，则安全停止
3. 手动操作：控件的物理驱动应导致状态转换，并且始终优先于驾驶员输入

命令映射

车辆接口必须将车辆控制命令消息映射到导致请求命令的物理车辆中的致动。

这可能涉及当前速度和请求信息与特定油门电压之间的某种映射。

类似地，对于转向角，根据从方向盘角到前轮角的一些映射，可以命令电压满足给定的车轮角。

基本原理 ：以这种形式使用命令简化了控制器开发，并将车辆特定信息隔离到车辆接口。

如果在接口不能满足的字段中提供非零值（例如后轮角度），则应忽略该字段并报告警告。

基本原理 ：尝试将车辆动力学修正为非零值时，由于堆栈未正确配置或数据未正确初始化，因此与警告相对应，这超出了车辆接口的关注范围。

车辆接口还必须满足以下映射：

理由 ：这是为了简化控制器的开发。 这允许控制器保持正向和反向的符号一致。 此外，这消除了为复杂的正反转操作（例如平行停车）控制换档行为的需要，从而简化了运动规划器的开发。

零订单持有

在控制命令之间，应保持最后命令的油门、转向角和车辆状态。

基本原理 ：车辆界面没有未来规划信息（例如轨迹），因此它不能也不应该尝试进行任何推断。 显式保持最后一个命令提供一致且可重复的行为以简化控制器开发。

状态报告

车辆界面应定期报告有关适当主题的车辆状态和里程计。

基本原理 ：自动驾驶堆栈的其余部分需要此信息，例如用于行为规划目的、状态估计等。

不安全的命令拒绝

不安全的命令组合应该被忽略或平滑。

这些不安全行为包括但不限于：

• 以非零速度在行驶、停车和倒车之间换档
• 控制命令中的高频振荡

基本原理 ：当车辆速度不为零时，应限制换档行为。 如果允许换档，可能会损坏汽车，并可能导致用户不适或受伤。 以非零速度在行驶、停车和倒车之间换档绝不是有效的操作。

基本原理 ：控制命令中的高频振荡表明堆栈中存在问题。 这种行为可能导致用户不适，或触发车辆电气控制系统的故障。

超时回退行为

如果控制命令在指定时间段内未到达，则车辆界面应恢复为简单的回退行为。

这种后备行为应包括：

• 激活危险灯
• 保持转向角平直
• 以自信的速度停止

基本原理 ：如果上游堆栈发生故障，应该有一些简单的默认行为可以使车辆进入安全状态。

基本原理 ：危险灯是向其他驾驶员发出故障已发生信号的标准手段。

基本原理 ：笔直的轨迹对于其他驾驶员来说是最可预测的，并且不太可能转向不可驾驶的空间

基本原理 ：应该进行果断减速，以便车辆可以快速停下来，但不要过于激进，以至于其他驾驶员没有时间做出反应。

手动覆盖

当操纵车辆的方向盘、制动器或油门时，车辆界面应脱离并将控制权交给用户。

理由 ：自动驾驶汽车仍在开发中。 负责控制的安全驾驶员可能知道首选的行动方案。

当手动启动车辆状态时，此命令应优先于自动驾驶堆栈的命令（例如前灯、危险灯、喇叭等）

理由 ：自动驾驶汽车仍在开发中。 负责控制的安全驾驶员可能知道首选的行动方案。 此外，对于车辆接口提供商来说，完全覆盖所有输入模式可能很困难。

参考

• AutowareAuto#62
• Autoware.AI 车辆界面设计
• DataSpeed ADAS 套件

相关消息类型

阿波罗：

• 车辆信号
• 雷克萨斯
• 驱动状态
• 车辆状态

汽车件：

• 加速命令
• 刹车命令
• 控制命令
• 指标命令
• LampCmd
• 远程命令
• 转向命令
• 车辆命令
• 车辆状态