求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
要资料
 
追随技术信仰

随时听讲座
每天看新闻
 
 
目录
Autoware.Auto
安装
系统依赖性和目标环境
使用 ADE 安装
使用 ADE 安装 arm64 系统
没有使用 ADE 安装
SVL 仿真器
使用
自动代客泊车示范
F1Tenth 演示1
F1Tenth 演示2
启动和测试行为计划
启动和测试全局计划
地图创建
初始化 NDT 定位器
运行 EKF 过滤器进行本地化
3D感知堆栈
记录/回放计划
使用rosbag进行本地化演示
Autoware Auto启动场景仿真器
建立
设计
Autoware Auto常见的设计-1
Autoware Auto常见的设计-2
Autoware.Auto 控制器设计
Autoware.Auto 驱动程序设计
Autoware.Auto 设计融合
Autoware.Auto 本地化
Autoware.Auto 的地图
Perception设计
Autoware.Auto 的 设计计划
Autoware.Auto 的 设计跟踪
Autoware.Auto 的 预测
Autoware.Auto 的系统
Autoware.Auto 的工具
Autoware.Auto 提供的指南
 
 
Autoware.Auto 的跟踪设计
李澎涛,俎涛 翻译(火龙果软件工程)
797 次浏览
6次  

目录

对象跟踪架构

目的/用例

本文档定义了对象跟踪器遵循的高级架构。

架构

该系统设计背后的核心思想是我们希望在跟踪管道中使用多个输入。 通常也很难同步不同的输入。 该架构以这两个假设为指导:它允许在每条消息可用时尽早处理它,同时仍然使用其他传入消息。

警告 由于目前 Autoware.Auto 中消息的设计方式,我们将 DetectedObjects 消息用于集群和机器学习 LiDAR 输入。 这不应该是这样。 聚类应该输出一个无形的点(凸包在这里似乎是一个很好的折衷),而 DetectedObjects 消息应该有一个明确的形状,比如一个盒子或一个圆柱体。 这将允许跟踪对象的形状并利用这些类型的其他差异。 这还没有实现。

工作流程

跟踪器的基本操作如下:

  1. 将不同的感知输入与现有轨迹相关联
    1. 每个输入都被转换成一个共同的参考系
    2. 轨迹被预测到输入对应的时间戳
    3. 每个输入可以使用不同的关联方法
  2. 更新曲目
    1. 每个感知输入可以为轨迹贡献不同的信息
    2. 例如,LiDAR 集群提供轨道位置、方向和尺寸更新
    3. 图像检测提供轨迹分类更新
  3. 轨道运动学更新由使用恒定加速度运动模型的 EKF 执行。 轨道的分类状态也使用专门的 EKF 过滤
  4. 创建新曲目
    1. 与任何现有轨道无关的所有输入都将发送到轨道创建模块
    2. 根据配置的轨道创建策略,新轨道被创建并且仍然未使用的输入被发布为“障碍”(不是轨道)
    3. 一种可能的轨迹创建策略是从具有相应图像检测关联的每个 LiDAR 集群创建轨迹。 图像检测通常不用于创建轨迹,因为仅从图像检测无法可靠地估计 3d 位置和方向
  5. 修剪一段时间未收到更新的曲目

子模块说明

本节将对上述工作流程中提到的每个子模块进行高级概述。 有关更详细的描述,请参阅特定于子模块的设计文档。 为每个子模块描述的功能可能尚未实现。 这充当了指路明灯。

关联

用于跟踪关联的 LiDAR 集群

Mahalanobis 距离用于计算每个轨迹和检测之间的对应分数。
基于面积和欧式距离的门控是为了减少必须计算分数的可能轨迹检测对的数量。
一旦计算出分数,分配将通过匈牙利算法进行。 该算法被修改,以便它可以处理每个检测轨道对可能没有有效分数的情况。 设计文档
中的更多详细信息

跟踪关联的图像检测

轨迹被投影到图像平面上。
IOU用作track和detection之间的对应分数。 设计文档
中的更多详细信息

视觉 - 激光雷达集群融合

本节解释了为什么我们有两个不同的块(即,跟踪关联的图像检测和集群 <--> 图像关联)而不是只有一个块(集群 <--> 图像关联)

假设:
一般来说,视觉检测的频率低于 LiDAR 集群

LiDAR 集群通常以 10Hz 发布。 来自环绕摄像机的视觉检测通常以较低的速度发布。

原因:
基于假设,我们不会让 LiDAR 集群和视觉检测在相同的确切时间查看相同的确切对象。
轨道具有状态信息,可以更容易地预测轨道在任何给定时间戳的位置。 这使得将轨迹与视觉检测相关联变得更容易、更准确。
但并非所有轨道都可以与视觉检测相关联。 对于刚刚进入视野的新物体尤其如此。
这意味着我们不能忽略不相关的视觉检测。 使用它们的最佳方法是将它们与 LiDAR 集群相关联。
激光雷达集群不会像视觉检测那样来自确切的时间戳,但我们可以增加关联的容差。 与仅使用 LiDAR 集群相比,这使我们能够在更长的范围内创建准确且稳定的轨道。

使用 SVL 仿真器运行多目标跟踪器

设置仿真器

autoware 中的对象跟踪器旨在订阅基于激光雷达集群的对象和来自视觉的 2d 检测。 要设置仿真器来执行此操作,请更改车辆的传感器配置。 转到“库”图标下的“车辆”页面,选择所需的车辆并单击其上的“传感器配置”部分图标。 单击页面底部的“创建新配置”按钮。 设置配置名称并选择“ROS2ForUnitySVLBridge”作为桥接器。 单击 Visual Editor 窗口附近的“{...}”符号。 将此处 的内容复制并粘贴 到框中。 创建一个使用这辆改装车辆和您选择的地图的仿真。 当前的演示旨在用于 AutonomouStuff 停车场地图。

运行跟踪器

转到“仿真”页面,点击浏览器窗口上的“运行仿真”按钮以启动一开始创建的仿真。

运行以下启动命令以启动跟踪器,

ros2 启动 autoware_demos object_tracker_lidar_single_camera_lgsvl.launch.py

默认情况下,此命令使用 NDT 定位器来获取自我车辆状态。 但是 NDT 定位器需要一个仅适用于 AutonomouStuff 仿真器地图的点云地图。 如果您想在其他仿真器地图(例如 BorregasAve )中运行跟踪器,请运行以下命令来禁用 NDT,

ros2 启动 autoware_demos object_tracker_lidar_single_camera_lgsvl.launch.py​​ use_ndt:=False

运行以下启动命令以启动带双摄像头的跟踪器,

ros2 启动 autoware_demos object_tracker_lidar_dual_camera_lgsvl.launch.py

跟踪节点

这是 tracking_nodes 包装的设计文件。

目的/用例

这是包周围的 ROS 层包装器 tracking 。

设计

DetectedObjects 和(可选) ClassifiedRoiArray 消息与 Odometry 或 PoseWithCovarianceStamped 消息时间同步,然后将其转发到更新轨道状态的跟踪器实现。 然后获取并发布更新的曲目。

假设/已知限制

  • 如果 use_vision 设置为 True 则轨道创建策略将自动更新为 LidarIfVision
  • 如果 use_vision 设置为 True 并且没有接收到视觉消息,则不会发布任何轨道,因为创建策略需要与视觉关联

输入/输出/API

输入主题:

  • “检测到的对象”
  • “classified_rois”(可选)
  • “里程计”

输出主题:

  • “跟踪对象”

参数:

  • use_vision - 将此设置为 true 以订阅 ClassifiedRoiArray 主题。 这也意味着 vision_association 需要在 params 文件中定义部分
  • use_ndt - 将此设置为 true 以使跟踪器使用 Odometry 来自 NDT 的 msg。 False 将使跟踪器使用 PoseWithCovarianceStamped 来自的 msg lgsvl_interface

有关演示,请参阅 使用 SVL 仿真器运行多对象跟踪器

检测到的对象关联器

这是在对象跟踪节点中使用的检测到的对象关联器的设计文档

目的/用例

检测到的对象关联器模块将检测与相似的轨迹配对,以便可以更好地估计轨迹的新状态,或者可以创建新轨迹或
修剪现有轨迹。

设计

检测到的对象关联器模块使用马氏距离来计算轨道与检测的“相似程度”。 此成本用于解决匈牙利分配器问题,该问题返回检测和跟踪之间的一对一关联。 某些轨迹/检测可能没有任何对应的关联。

假设/已知限制

  • 假设检测是具有非零面积的凸多边形
  • 假设检测的顶点逆时针排列
  • 轨道消息中的每个轨道都有一个形状向量来支持铰接式车辆。 关联者仅使用向量中的第一个形状来进行关联

输入/输出/API

输入:

  • 检测列表
  • 曲目列表

参数:

  • 轨迹与其相关检测之间的最大面积比
  • 轨道与其相关检测之间允许的最大欧几里得距离
  • 布尔值,用于控制在大于配置的阈值距离的情况下是否使用检测的最小边作为阈值距离

输出

  • 跟踪和检测之间的关联

接口:

  • 调用 assign() 检测和跟踪列表。
    这将返回一个结构,其中包含,
    1. 每个轨道的相关检测的索引,或者 AssociatorResult::UNASSIGNED 如果轨道无法与任何检测相关联
    1. 没有关联轨迹的所有检测的索引
    1. 没有关联检测的所有track的索引

内部工作/算法

  • 找出接收到的轨道和检测的数量并适当地初始化分配器
  • 循环检测和跟踪。 对于每对检查它们是否可以根据配置的参数进行关联
  • 如果一对满足门控参数,则计算它们之间的马氏距离并在分配器中为该对分配权重。 否则,忽略该对
  • assign() 在分配器中 调用函数
  • 循环遍历所有关联以找出没有关联的轨迹和检测

错误检测和处理

  • 如果轨迹或检测形状不满足上述假设,则抛出异常

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

  • 考虑多对一关联
  • 考虑几何相似性度量

相关问题

  • #897 - 初始实施

ROI关联器

激光雷达和雷达检测机器人周围的 3D 物体。 如果这些对象的视觉测量可用,则可以将它们关联起来以加强 3D 信息。

目的/用例

可以通过融合来自相互补充的多种模式的数据来加强跟踪。 计算机视觉是此类模式之一,它可以提供某些优势,例如在适当光照条件下能够比其他传感器更好地提取语义信息。

为了将视觉检测与 3D 检测结合使用,需要一个关联器,该关联器可以将图像中的 ROI 与 3D 检测相关联。

设计

GreedyRoiAssociator 将通过首先将每个 3D 对象投影到图像平面,然后根据当前设置为 IOUHeuristic 的匹配度量选择最佳匹配来将 3D 对象与图像中的 ROI 关联。 3D 检测可以来自激光雷达、雷达或任何其他产生 3D 输出的传感器,也可以是跟踪器中已经存在的轨迹。

内部工作/算法

有关如何执行投影的更多详细信息, 请参阅 投影文档。

预计总复杂度将由关联操作确定,其最坏情况复杂度为 Ø ( ñ 吨 ñ R ( 五 R + 五 吨 ) ) 在哪里 ñ 吨 是 3D 对象的数量, ñ R 是 ROI 的数量, 五 R 是 ROI 上的最大顶点数,并且 五 吨 是 3D 对象上的最大顶点数。 复杂性背后的解释是,每个对象都与循环中的每个 ROI 进行比较,其中在 IoU 计算期间计算形状的区域。 面积计算的复杂度由每个形状的顶点数决定,总复杂度为 Ø ( 五 R + 五 吨 ) 对于每个对象-ROI 比较。

  • 不在图像平面上的对象不关联
  • 没有匹配 ROI 对应对象的对象不关联
  • 没有匹配对象对应物的 ROI 不关联
  • 要将 ROI 和对象视为匹配,它们之间的计算 IOU 必须大于阈值。

输入/输出/API

输入:

输出:

在仿真器中计算相机的内在函数

传感器 json 文件将包含视野(它是垂直 FOV)和纵横比(宽度和高度)。 使用这些数字计算参数如下,

a s p e c t _ r a t i o = w i d t h / h e i g ht _

霍里兹 _ _ _ _ o n t a l_f _ _ o v = 2 * t a n − 1 ( 吨 一 ñ ( F 电压 _ / 2 ) * a s p e c t _ r a t i o )

F X = w 我 d t h / 2 * t a n ( 0.5 * h o r i z o n t a l_f _ _ o v )

F 是的 = h e i g h t / 2 * t a n ( 0.5 * F 电压 _ )

C X = w 我 d 小时 / 2 _

C 是的 = h e i g 小时 / 2 _

相关问题

  • #983:在对象跟踪器中集成视觉检测
  • #1244:将激光雷达集群与视觉检测相关联

轨迹生成器

目的/用例

自动驾驶系统的对象跟踪涉及将每一帧中的新检测与跟踪器记录的轨迹相关联。 每帧都有新物体进入车辆的视野,感知传感器也可能每帧都有误报。 这意味着跟踪器需要一个模块来评估这些不符合匹配标准的检测以与任何现有轨道匹配。 理想情况下,该模块只需要为来自真实对象的检测创建新的跟踪,跟踪器可以将其纳入其操作。

设计

轨道创建背后的核心思想是我们使用策略模式,其中大部分轨道创建工作实际上由轨道创建策略处理。 autoware ::perception::tracking::TrackCreator 类将策略作为模板参数,并在接收到用于创建轨道的数据时调用它。

笔记 虽然这是一种多态行为,但我们使用编译时多态,因此轨道创建模块的输入类型的有效性在编译期间得到验证。

内部工作/算法

autoware ::perception::tracking::TrackCreator 类本身并没有做太多的工作,但它遵循以下描述的策略之一:

仅限激光雷达集群

  • 打电话 create_tracks(const ObjectsWithAssociations & objects) 。 此方法将为每个提供的集群创建一个轨道。 这里只考虑不与其他任何东西关联的集群。
  • 使用此策略不需要有效的 GreedyRoiAssociator 对象指针。 可以初始化为nullptr
  • 该策略不会实现 消息类型的 add_objects() 功能。 ClassifiedROIArray 调用它会导致抛出异常

激光雷达集群IfVision

  • add_objects() 使用视觉检测消息和视觉跟踪关联的结果 调用。 此方法将遍历与轨道无关的每个视觉检测并将其存储在内部。 每次调用此函数时,都会在内部创建一条新的视觉检测消息并将其推送到缓存中
  • 打电话 create_tracks(const ObjectsWithAssociations & objects) 。 此方法将首先尝试 max_vision_lidar_timestamp_diff 从 LiDAR 集群 msg 标记中找到视觉检测。 如果它发现这样的消息,它将尝试将 LiDAR 集群和视觉检测相关联。 仅从与视觉检测匹配的 LiDAR 集群创建新轨道
  • 使用此策略需要在 VisionPolicyConfig struct 对象中初始化一个有效的 TrackCreatorConfig struct 对象。

参数

  • TrackCreationPolicy - 根据上述说明选择一项可用的策略
  • 默认方差和噪声方差 - 这些是用于初始化新 TrackedObject 对象的值
  • VisionPolicyConfig - 需要为 LidarClusterIfVision 策略初始化此结构
    • 从 base_link 转换为相机
    • iou_threshold - 计算 LiDAR 集群和视觉检测的最小 IOU 值
    • 相机的内在参数
    • max_vision_lidar_timestamp_diff - 视觉检测消息戳和 LiDAR 集群消息戳之间的最大差异要考虑关联

假设/已知限制

  • 该模块假定 create_tracks 每次收到 LiDAR 对象消息时都会调用
  • 假设模块中的所有函数都从同一个线程调用,除了 add_objects(ClassifiedROIArray, ...) 使用线程安全数据结构并且可以从不同线程调用

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

  • 支持雷达检测
  • 支持机器学习 LiDAR 对象检测

跟踪测试框架

这是 tracking_test_framework 包装的设计文件。

目的/用例

我们需要一个数据生成和测试框架来测试 AutowareAuto 中的对象跟踪模块。 该框架应该使用户能够创建具有易于定义的规范的测试用例。

假设/已知限制

  1. 现在我们假设跟踪发生在 2D 中。 因此,被跟踪的对象被假定为简单的 2D 形状。
  2. 线的形状用固定的端点表示,不是无限的。

API

该框架将提供 API 用于为被跟踪对象生成数据,这些数据将被馈送到用于跟踪算法的单元测试中。 以下内容可被视为待完善的初稿:

1.行人( const Eigen::Vector2f & starting_position,
const autoware::common::types::float32_t starting_speed,
const autoware::common::types::float32_torientation_deg ,
const autoware::common::types::float32_t turn_rate_deg_per_sec)
2.汽车( const Eigen::Vector2f & starting_position,
const autoware::common::types::float32_t starting_speed,
const autoware::common::types::float32_torientation_deg ,
const autoware::common::types::float32_t turn_rate_deg_per_sec,
const Eigen::Vector2f & size);
3. 激光雷达( const Eigen::Vector2f & position, const uint32_t number_of_beams,
const autoware::common::types::float32_t max_range);
4. 场景(常量激光雷达 & 激光雷达,常量std::vector<std::unique_ptr<TrackedObject>> & 对象);
5. autoware_auto_perception_msgs::msg::DetectedObjects Scene::get_detected_objects_array(
const bool most_only)常量
6.无效场景::move_all_objects( const std::chrono::milliseconds dt_in_secs)

内部工作/算法

  1. 该框架提供了一个称为 Shape 类的 2D 形状生成器接口,用于在 2D 中表示被跟踪的对象。
  2. 这个抽象类由 扩展而来 , Line 每个类 分别是 LiDAR ray、汽车和行人的程序化表示。 这些子类实现了它们自己的函数版本,该函数返回 与 的交点 , 从而模仿当来自传感器的光线接触对象表面时返回对象上的跟踪点的行为。 Rectangle Circle intersect_with_line Line Rectangle Circle
  3. 为了能够初始化 Line 和使用它,我们需要:起点表示为 2D 向量 [xs,ys],终点表示为 2D 向量 [xe,ye]。 线的方向和长度由坐标系中的起点和终点确定。
  1. 为了能够初始化 Rectangle 和使用它,我们需要:中心点表示为 2D 向量 [xc,yc] 和大小(长度 * 宽度)表示为 2D 向量 [l, b] 加上方向 [角度] wrt x 轴度数表示为浮点数。 Rectangle 的边界和角点将由提供的这些输入确定,当我们尝试获取与 Line .
  2. 为了能够初始化 Circle 并使用它,我们需要:中心点表示为 2D 向量 [xc,yc],半径 [r] 表示为浮点数。

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

  1. 实现 3D 形状生成器接口和获取交点的方法。
  2. 验证跟踪器输出的方法
  3. 为雷达等其他传感器模式生成对象

相关问题

https://gitlab.com/autowarefoundation/autoware.auto/AutowareAuto/-/issues/886

预测

可以使用从点的 3D 位置和相机的内在函数导出的几何比例来估计 3D 点在图像平面上的投影。

目的/用例

可以通过将 3D 点投影到相应的图像平面来估计 3D 点的像素对应关系。 这对于将空间中的几何结构与图像上捕获的几何结构相关联很有用。

设计

点的投影是通过应用投影矩阵来完成的 磷 :

λ ⎡ ⎣ ⎢ X p 是的 p 1 ⎤ ⎦ ⎥ = P ⎡ ⎣ ⎢ ⎢ ⎢ X 是 Z 1 ⎤ ⎦ ⎥ ⎥ ⎥

( X , Y , Z ) 是该点的 3D 坐标,并且 ( X p , 是的 p ) 是投影的像素坐标。 λ 是点相对于相机帧的深度。

磷 可以使用内在矩阵计算 ķ 和 ego-to-camera 变换 吨 根据等式 磷 = K 吨 . 内在矩阵定义如下:

ķ = ⎡ ⎣ ⎢ F X 0 0 s F 是的 0 ○ X ○ 是的 1 ⎤ ⎦ ⎥

F X 和 F 是的 是以像素为单位的 x 和 y 轴上的焦距。 s 是像素偏移因子。 ○ X 和 ○ 是的 是像素主点偏移。 这些参数可以通过校准生成图像的特定相机来测量。

内部工作/算法

通过执行以下步骤完成投影:

  • 使用相机变换和内在函数构造投影矩阵
  • 投影代表 3D 形状的所有顶点
    • 相机后面的点被过滤掉
  • 计算围绕投影点的凸包。
  • 找到凸包和图像画布之间的交点
  • 返回相交的凸形作为图像平面上的投影

输入/输出/API

输入:

  • 相机内在函数
  • 相机变换
  • autoware_auto_perception_msgs::msg::Shape 表示 3D 形状。

输出:

  • 表示投影形状的顶点列表。

相关问题

  • #983:在对象跟踪器中集成视觉检测

 

 
欢迎参加课程:
数据建模方法与工具
MBSE(基于模型的系统工程)
基于 UML 和EA进行分析设计