域描述
该mapping子目录包含创建和发布用于自动驾驶的地图的节点和库，例如语义地图和 3D 点云地图。 中心页面
用于 Autoware.Auto 的 Lanelet2 地图
概述
Autoware.Auto 使用 Lanelet2 格式来定义环境中车道的几何和语义信息。 有关格式的详细信息，请参阅 Lanelet2 官方文档 。
一般来说，Autoware 期望 Lanelet2 地图根据上游定义创建，并进行一些小的更改。 以下部分解释了应如何为 Autoware.Auto 定义对象和标签。
笔记 当前的解释针对的是 自动代客泊车示范 ，并且可能会随着新的 ODD 而改变。
初始语义
对于 AVP 任务，Autoware 支持以下 Lanelet2 初始语义 ：
- Lanelet 用于定义行驶车道
- 定义停车位和停车通道区域的区域 请注意， Autoware.Auto 不使用 监管元素 （例如交通灯、交通标志、通行权等），因为它们在 AVP ODD 之外。
定义车道
车道应由 Lanelet 原语根据 Lanelet2 格式定义。 Autoware 使用以下信息。
Autoware中使用的信息：
- 参与者： vehicles Autoware.Auto 仅支持通道。 这可以 根据 Lanelet2 文档中的表格 type 由lanelet 间接定义，也可以 直接由 标签定义。 subtype participants
- speed_limit：Autoware 不会以超过此标签定义的值的速度行驶。
Autoware<strong>不</strong>使用的信息：
- 变道：在Lanelet2格式中，变道的可能性由lanelet边界的类型决定。 然而，Autoware 不支持变道操作，因此被忽略。
- 双向车道：在原始的 Lanelet2 格式中，车道可以定义为带有标签的双向车道 one_way=no 。 相反，Autoware 期望双向车道由两个方向相反的重叠车道定义。 以 AutonomouStuff 停车场地图 为例。
定义停车位
Autoware 期望停车位被定义为带有以下标签的区域对象：
- subtype=parking_spot ：带有此标签的区域将被视为停车位。
- parking_accesses=<list of parking access ids> ：这定义了通往最近车道的连接停车通道区域。 ID 列表应以 , （逗号）分隔
定义停车通道区域
Autoware 期望车道和停车位之间的可行驶区域被定义为具有以下标签的区域对象：
- subtype=parking_access ：带有此标签的区域将被视为停车通道
- parking_spots=<list of parking spot ids> ：这定义了与停车通道区域相连的停车位。 ID 列表应以 , （逗号）分隔。
- ref_lanelet=<list of lanelet ids> ：这定义了连接到停车通道区域的车道。 ID 列表应以 , （逗号）分隔。
Lanelet2 地图提供者
这是 lanelet2_map_provider 包装的设计文件。
目的/用例
该节点的这个目的是根据需要加载和分发lanelet2地图数据到其他节点。 Lanelet2 地图包含有关道路网络、交通法规、人行道和停车位的几何、路线和语义信息。 需要特定地图信息的节点应向地图提供者节点请求其所需的几何区域和内容。 然后地图提供者应该从更大的地图中提取该信息并将信息发送到相关节点。
具体用例（节点从lanelet2地图提供者节点请求具体信息）：
- 全局规划器节点 - 请求道路布局、小巷级别道路网络、停车位和可行驶区域，用于包含所需路线的起点和目标位置的有界地理区域，以及一些允许非直接路线的额外区域。 要发送的结果信息必须是有效的 lanelet2 映射，以允许构建路由图。
- 本地规划师 - 请求指定位置周围本地区域的道路布局、小巷级别的道路网络、停车位和可驾驶区域。 应给出区域的位置、方向 (?) 和大小，因为所需的地图范围取决于当前速度、机动类型等。
设计
Lanelet2 地图提供者的设计是典型的基于 ROS2 的 3 层设计：
- Lanelet2_map_provider基类提供到 lanelet2 库的接口，用于加载给定地图，并将几何和原始子地图提取为二进制消息
- 一个 ROS2 节点，它使用基类加载特定地图并定义服务以响应对子地图的请求
地图设计
目的/用例
点云映射旨在从传感器数据构建环境的 3D 点云地图，传感器数据传达有关感知代理周围环境的 3D 信息，可以直接像激光雷达一样，也可以像 2D 视觉 SLAM 那样间接。
输入用例
在线数据
这是一个用例，其中在车辆运行时构建地图，收集数据并实时定位自身。 在这个用例中，点云映射器旨在注册来自在线数据源的测量值，这些数据源可能包括原始或处理过的传感器数据，并构建一个环境地图，以进一步定位自身。
根据配准算法，映射器可以利用额外的定位源在映射过程中提供机器人姿态的初始估计。
在在线地图生成中，可能需要以下组件：
输出格式如下：
- 为每个注册的输入消息变换/姿势。
- 地图文件。
- 关联的元数据文件。
关联的元数据文件可以包含 earth -> map 给定地图的相关转换和基于接收到的扫描的时间戳、姿势估计和映射器的当前系统时钟的时间戳，具体取决于实现的时间戳策略。
离线数据
预录数据：
另一个常见用例是重放与要映射的位置相关的预先记录的数据堆栈。 当使用预先记录的数据时，可以像在线数据一样进行点云映射。 唯一的例外是映射器应注意地图创建的实际时间与数据的时间来源不同。
离线运行映射打开了运行更庞大的优化算法以更正地图和注册输入点云的可能性。
模拟数据：
在某些情况下，模拟环境的地图可能无法直接获得，可能需要手动映射。 在这种情况下，模拟器应该具有与在线数据相同的数据源。 在这种映射模式下，如果模拟器提供地面实况数据，环境可以获得精确的映射。
输出用例
本土化
映射器的注册部分有效地用作本地化的在线资源，因此可以满足 本地化设计文档 中指定的本地化器的输出用例。
或者，在创建并导出区域的准确地图（在线或离线）之后，该地图可用于稍后在给定区域中实现相对定位，而无需从头开始绘制环境地图。
可视化
可视化点云地图可以有各种用例，包括调试或定性评估定位性能。
点云变换
为映射过程注册的点云 map 在注册后转换为框架。 可以发布此数据以服务于需要地图框中数据的组件。 此过程可以节省稍后由转换器节点重新转换原始点云。
造型
环境地图可以用于本地化或可视化以外的目的。 环境的 3D 模型可用于许多领域，例如建筑、城市规划或建筑模拟和视频游戏。
要求
根据列出的用例，映射应满足以下功能：
- 将观察结果注册到正在进行的地图上。
- 通过将注册的点云附加到地图中来扩展地图。
- 检测回环并纠正地图或轨迹表示。
- 触发地图导出标准后，将地图对象连同与之关联的任何元数据一起写入文件。
要求 2. 意味着将数据附加到容器中。 为了保持系统在内存中的可预测性和静态性，映射的容量应该是固定的和预先分配的。 根据地图表示，可以使用像体素网格这样的结构来减少冗余或重叠点。
要求 4. 意味着定义地图创建策略以确定输出地图的内容和生成率。
要记住的另一件事是，当传入的点云与原点偏离太多时，要防止标量溢出。 在这种情况下， map 应该移动框架以保持与原点的偏移合理。
映射器应该是模块化和可配置的，以允许在实时在线配置和离线设置之间切换，该配置对在线映射系统的运行时约束更加宽松。
设计
输入：
输出：
- 注册观察的变换/姿势。
- 转换更新 map 框架放置的位置。
- 变换的点云。
- 以实现定义的格式映射文件。
- 实现定义格式的元数据文件。
- 映射为用于可视化的 PointCloud2 消息。
内部工作：
鉴于用例和要求，点云映射器预计能够按照以下工作流程执行。
在前端：
- 为容器分配内存。
- 对于每个收到的观察：
- 验证消息。
- 可选择在此步骤中选择关键帧。
- 将其注册到现有地图。
- 将注册/重建的点云附加到轨迹/地图表示
- （可选）检查闭环：
- 退出回调。
- 执行轨迹修正。
- 检查导出标准：
- 退出回调。
- 导出地图。
- 发布地图和/或过程的副产品，例如注册输出。
为了使地图创建灵活和可扩展，映射器应该允许以下结构和功能的灵活性和自定义：
- 输入类型
- 地图表示
- 轨迹表示
- 登记
- 闭环检测
- 轨迹修正
- 输入预处理
- 输出后处理
- 地图导出
- 副产品处理
无损检测映射节点设计
这个包包含用于基于 NDT 的映射的节点。
主节点是 从包 P2DNDTVoxelMapperNode 中继承 并专门用于映射的节点。 RelativeLocalizerNode localization_nodes |
