标签: 自动驾驶

一、前言 作为一名 高校的科研工作者 ，在高校的科研工作中，经常需要处理各种复杂的数据流，尤其是 视频采集和处理 的工作，对数据的实时性和精度要求非常高，我首次试用ADTF时，主要负责开发一个 集成FFmpeg的Filter组件 ，处理摄像头采集的raw数据，并对其进行H264编解和解码。在这个试用的过程中，我对ADTF的初步体验是它的设计 非常便捷 ，尤其是对于 图像和视频数据的处理。 通过这次开发，我对 ADTF的模块化设计、流数据传输机制以及其便捷的开发环境 有了更加深刻的认识。接下来，我将从多个角度详细分享我的试用体验，内容涵盖 ADTF的优势、工作流程中的亮点 ，以及 未来展望 等方面。 二、ADTF的用户界面与灵活性 在打开ADTF时，我觉得其 直观的GUI设计 非常的友好。作为一名高校科研工作者，我们通常需要频繁的调整实验配置、切换不同的开发场景，而ADTF的界面布局使得这些操作变得十分便捷。 其工具栏、Component、Sessions管理以及快捷命令栏 的存在，极大的 优化了工作的流程 。能够在搭建工作流时，迅速的找到所需要的工具和组件，并轻松的管理多个实验配置，这在需要进行多项实验的科研工作中尤其重要。 ADTF的模块化设计 使我能够快速自由的组合各种组件，构建适合 具体科研需求 的工作流。例如，我能够通过ADTF提供的Store模块，轻松地管理不同的数据流和实验配置。这种灵活性对于需要 快速迭代实验和算法验证 的科研工作来说非常有利。 三、便捷的组件开发 我在ADTF中开发的Filter组件，集成了FFmpeg进行H264图像数据编解码，这使得我能够处理摄像头采集的raw数据。ADTF提供了 标准的图像数据流定义 ，使我可以快速上手，并通过 自定义的数据流类型进行数据的高速传输。 让我印象深刻的是，ADTF允许我创建自定义的流类型，并将编码后的视频数据发送至下一个Filter进行解码。这种模块化的设计对于处理复杂的多步数据流非常有帮助，尤其是在 处理视频和音频等 连续数据时。 ADTF的流数据传输机制非常稳健 ，特别是在 高速数据吞吐 情况下，它依然能够保证数据的完整性和及时性。例如，当我处理大规模视频数据时，ADTF通过其文件的流数据传输体系很好地管理了数据流的传输，确保没有出现数据丢失的现象。这一点在要求 高精度 的场景下， ADTF的表现非常好 。 此外，ADTF的组件开发过程也充分展示了其 灵活性 。在开发Filter组件时，ADTF中可以自定义流类型，不仅能与标准化的数据流兼容，还能针对特定需求自己定义。通过这种方式，我可以轻松的将编码后的视频数据 传输至下一个 解码或者处理视频数据的组件，实现多步数据流处理。在整个开发过程中，我清晰地感受到了ADTF模块化设计所带来的便利，它允许我 根据不同的实验需求进行自由组合和扩展。 四、丰富的工具箱和组件 ADTF还有一个非常好的亮点是它 丰富的工具箱 。我在开发组件的过程中直接使用了ADTF自带的Windows摄像头驱动采集数据，避免了繁琐的硬件配置。此外，ADTF还提供了Qt以及foxglove等显示组件，使我能够实时监控摄像头捕获的视频流，很大程度上方便了我的开发和测试。这种 预制组件的存在大幅度缩短了开发时间 ，我可以把更多的精力集中在数据处理的核心逻辑上。 在科研项目中，快速的验证新算法和新想法是我们的日常工作。 ADTF通过大量现成的组件，帮助我们在短时间内可以搭建一个完整的测试环境 。例如：我可以迅速继承已有的摄像头采集组件，并通过简单的操作和配置就可以完成视频流的显示和存储。这种集成工具的便利性是在科研工作中快速迭代优化的重要支撑。 五、外部库与ADTF完美结合 在科研项目中，大部分的功能需要 依赖外部库 ，比如OpenCV、FFmpeg…，在这次的开发过程中，我通过FFmpeg对摄像头采集的raw数据进行H264编解码。 ADTF的开放性和模块化 使得FFmpeg的集成过程十分顺畅，通过Filer组件可以轻松调用FFmpeg的功能，将raw数据进行编码，并在解码阶段还原数据进行显示。 FFmpeg强大的视频处理能力与ADTF的稳定数据流传输机制相结合，使我能够达到项目中要求的实时数据处理。通过把FFmpeg集成到ADTF中，我能够以较低的系统资源消耗完成高效的视频编码和解码，还可以在我设计不同的试验方案时，快速的帮我搭建适合试验方案要求的工作流。 ADTF与FFmpeg的结合组件展现了非常出色的扩展性和稳定性。 六、未来展望 通过对ADTF的使用，我认为ADTF为高校的科研人员提供了一个强大的数据处理和开发平台，A DTF在处理大规模数据流、视频数据编解码等领域具有极大的潜力。 这种模块化设计使我们能够轻松定制复杂的工作流程，特别是在处理多个传感器数据和视频流时，ADTF提供了极高的灵活性。 在未来对ADTF的使用中，我将会进一步探索ADTF在 自动驾驶、智能交通系统等领域 的应用，并希望能够看到它在数据处理和算法开发中的更多突破。

为确保AD/ADAS系统的安全性，各大车企通常需要 收集、处理和分析 来自于摄像头、激光雷达等传感器的数据，以找出提高系统安全性和性能的方法。然而在数据收集过程中，不可避免地会出现 大量无价值数据 ，造成 数据泛滥 的情况，进而影响数据的分析处理进程。为此，本文将为大家分享如何通过 合适的指标 及 分析工具 ，实现 数据的高效管理、解读和正确分析 ，以避免数据泛滥的不利影响！ 一、现有问题 对于汽车制造商来说，确保AD/ADAS系统的安全性通常需要 收集大量数据。 为了开发、验证和改进自动驾驶系统，流程通常是相同的：在各种条件下反复进行驾驶测试，累积大量里程。 这些来自不同来源（摄像头、GPS、激光雷达、仿真等）的驾驶日志随后会被处理和分析，以找出提高系统安全性和性能的方法。由于涉及 大量传感器 、 众多不同的使用场景 以及 大量的行驶里程 ，需要 处理的信息量 会迅速呈 指数级增长。 面对如此大量待处理的信息，很容易让人感到不知所措。收集到的很多内容可能 毫无用处 （设想开车行驶的数千公里却什么有趣的事情都没发生），而且在这个过程中，一些信息可能会 丢失或损坏 。此外，仅收集数据是不够的。这些数据需要被 管理、解读和正确分析 。数据池越大，这个过程就越痛苦和昂贵。 二、康谋方案-避免数据泛滥的2个关键 基于上述问题，康谋提出2个关键点，助力AD/ADAS系统开发、验证和改进过程，避免被庞大的数据淹没，从中获得最大受益： 1、关键点1 –通过指标和算法聚焦于相关发现 第一个关键点在于一个简单的原则: 必须尽可能减少数据池,只保留最相关的信息。 内容越少,处理和分析越快 。此外,专注于更小的有效信息集合可以降低存储成本和维护负担。 为了减少初始内容池,可以创建 有用的信息块， 或者说 "指标（metrics）" ,以更简短和有意义的方式总结和描述它。这些指标可以根据使用案例指代多种事物： 统计数据、事件或甚至场景 。一旦它们与业务需求对齐，就有必要通过 适当的算法 生成。 设想一下您正在努力提高新车辆的 安全性和舒适性。 具体来说,您正在试图了解如何减少车辆进行危险紧急制动的情况,即车辆突然刹车导致乘客不适，并构成潜在安全隐患的情况。与其手动检查历史驾驶记录去找到这些情况,不如 构建一种算法 来完成这项工作。 例如，遍历驾驶测量数据,计算车辆的减速度,并标记超出您定义的舒适限度的时刻。此外,该算法还可以计算其他参数,如与其他车辆的距离,以了解发生这种情况的原因。一旦初始数据已根据所选指标进行标记,您就可以将精力集中在这些上面。 2、关键点2 –使用全面的分析工具可视化见解 经过了关键点1，最初的原始数据池就被压缩成了少量的相关内容。它们需要 被可视化 、 分析和共享 ,以便能够用于新车辆、传感器或软件的开发或验证。所有这些都可以通过联系发现与强大的分析平台来完成。 这是一个可以 汇总所选指标并控制信息流 的集中点。根据具体情况,有许多可视化检查的例子:分析地图上近处的碰撞事故、在时间序列图上提取切入场景、可视化相机图像上消失的物体等。好用的可视化也有助于分析,并允许生成可以跨团队或任何利益相关者共享的报告。 为了说明这一点,让我们继续以上一节中描述的 安全和舒适性 为例。一旦找到您初始驾驶日志中所有感兴趣的紧急制动情况,就可以理解它们是 如何以及更重要的是为什么发生 。一种解决方案是在地图上显示这些情况,并绘制相关车辆和周围障碍物的信息。然后可以将这些发现 传递给相关团队 ,进而改进系统。 三、小结 总而言之，为了从收集的数据中获得最大收益,需要将其归纳为 有用的指标 ,然后在一个 强大的分析工具 上显示这些指标,以便于 可视化和共享 。要实现这些，需要拥有一个 合适的架构 作为处理流程的基底,使算法和工具能够顺利运行。

随着自动驾驶技术的快速发展，自动驾驶的研发逐渐形成一整套的流程，包括 数据采集，清洗标注，算法训练，仿真测试 到 量产 等各技术环节。通过复杂的步骤从原始数据中提出高价值的信息，其中对原始数据的精准采集是实现车辆环境感知的基石。毫米波雷达因其出色的测距、测速能力以及对恶劣天气的鲁棒性，成为不可或缺的传感器之一。 本文将以4D毫米波雷达ARS548为例，分享毫米波雷达如何快速实现数据采集，可视化及存储策略。关于毫米波雷达的特性可进一步了解文章 《毫米波雷达技术解析》 。 一、ARS548毫米波雷达概述 ARS548 是 4D高分辨率成像毫米波雷达（4D High Resolution Radar），如图1所示。它能够有效的测量 距离（Range），速度（Velocity），水平角度（Azimuth） 和 俯仰角度或高度（Elevation） 四个维度的信息，具备感知目标三维空间位置能力。具备以下特性： 图1：ARS548（图片来源于网络） 1.探测距离与视场角： 最大探测距离可达300米，水平视场角为±60°，垂直视场角为±4°至±14°。 2.数据输出： 支持最多800个Detection和50个Object的同时输出，测量周期为50ms至100ms可调。 3.接口： 采用100 BASE-T1接口，支持通过车载以太网转换器与标准以太网设备进行通信。 4.通信协议： 数据通过UDP协议传输，使用多播地址方式进行数据传输。 二、硬件集成 为了能快速采集到毫米波雷达的数据，需要对其进行 硬件集成与连接 ，如图2所示。 图2：Radar 硬件连接方案 以同时连接3个毫米波雷达为例，整个系统均支持12V的供电运行，可快速实现各设备稳定供电运行。在数据链路采集上，需要将车载以太网接口的数据转换到标准以太网，这一转换过程涉及以下步骤： 1. 网口转换： 使用如 康谋NETLion100转换器 ，将车载以太网信号转换为标准以太网信号。NETLion100集成了网络分线器(Tap)和双介质转换器于一身，支持BroadR-Reach®网络信号与100BASE-TX以太网之间的双向转换，并提供LED信号实时显示数据传输质量，可快速进行数据转换和分析。 2. 数据传输原理： 雷达数据以UDP包的形式发送至指定的多播地址， 康谋BRICK plus 设备通过网络接口接收这些数据包。BRICKplus提供广泛的接口支持多个传感器同时连接，实现高带宽数据的采集、处理和记录。 3. 采集与监控： 在BRICK plus端，可以使用Wireshark等网络分析工具来捕获和分析从雷达发送的数据包，检查数据包是否正确传输。 三、软件开发 为了采集到毫米波雷达输出的点云数据，需要理解数据的传输形式并能够实时解析。具体来说需要解决如下的问题： 1.数据采集 ：实时从ARS548雷达获取原始数据，这要求系统能够与雷达硬件接口进行高效通信，并且能够处理高频率的数据流。 2.数据解析： 将原始数据转换为可读的格式，如目标的距离、速度和角度。需要对雷达数据包进行解码，并提取出有用的信息。 3.数据可视化： 将解析后的数据以图形化的方式展示，便于分析和监控。需要实时更新数据显示。 ROS提供了模块化的节点系统 ，便于管理和扩展。每个节点可以独立开发和测试，使得系统的整体复杂性得到有效管理。十分契合我们对问题的拆解以及功能节点的完成。此外采用ROS的发布/订阅模型可以实时采集传输的雷达数据。 对于单个毫米波雷达的采集，解析和可视化，可以通过在ROS中对应 创建3个节点 来实现。3个节点分别负责Radar设备接收UDP数据，解析并发布ROS消息，以及将雷达检测和对象信息转换为可视化Marker消息。 针对3（多）个毫米波雷达的同时采集，我们采用 每个节点同时发布和订阅多个topic数据 实现同时采集和传输。并且为了实现多个雷达数据的同时显示，采用 Foxglove 进行可视化呈现，呈现效果如图3所示： 图3 ：Radar 可视化 随后， 采用ROSbag进行数据存储 ，能够确保数据的完整性和准确性。 四、总结 通过 集成高性能的硬件设备 和采用 ROS框架 ，实现了毫米波雷达数据的高效采集、实时处理和直观可视化，同时支持多雷达系统的数据同步采集和存储，提供了一个稳定、灵活且可扩展采集方案。

在上期 数据隐私和匿名化系列 文章中，我们主要分享了 《中国个人信息保护法》（PIPL） 和 《欧盟通用数据保护条例》（GDPR） 在 涵盖范围、定义、敏感信息 等方面的异同点，今天，我们将重点分析PIPL与GDPR在 数据处理行为及其基础合法性 方面的异同，旨在帮助车企更准确地把握数据隐私保护法规的要求，有效应对相关挑战，推动自动驾驶行业健康发展。 一、PIPL和GDPR的异同点 1、数据处理行为定义 两部法规（PIPL和GDPR）均明确界定了 不同的数据处理行为 ，这些行为将触发各自法规的管理范畴。此处所提及的信息， 已不再局限于敏感信息 ，而是涵盖了两部法规所规定的 所有相关信息 。 在 英文版的PIPL 中，数据处理行为被表述为“ Handling ”，而 GDPR 则使用 “Processing” 一词，两者在本质上并无区别。然而，在 数据处理行为的定义上，两部法规却存在些许差异 。 PIPL中的“Handling”涵盖了 收集、存储、使用、加工、传输、披露以及删除个人信息 等一系列行为。相较于PIPL， GDPR 关于数据处理行为的定义则 更为详尽 ，除了包含上述相同的行为外，还涉及到了 个人数据的检索、咨询 等多个方面。 但实际上，当我们深入探讨PIPL中定义的数据处理行为时，相关法律专家指出： “在中国境内处理个人信息时，GDPR所涵盖的任何数据行为都需要被纳入考虑范围，即使PIPL并未完全列举出所有要点。” 由此可见，在各自司法管辖区域内处理相关数据时，任何数据处理行为都将受到该区域法律条例的约束。 2、数据处理基础合法性 为了进一步对比数据处理行为的异同，我们在此列举了中国的《个人信息保护法》（PIPL）与欧盟的《通用数据保护条例》（GDPR）在 数据处理基础合法性 方面的相关规定。 “同意”（Consent） 是指数据主体明确授权或表示同意其个人数据被处理的行为。这种同意必须是建立在充分知情的基础上，且必须是明确且自愿给出的。 除了“同意”这一点外，我们重点关注两部法律在 合法利益（Legitimate Interest）和公共利益（政府任务）（Public Interest/Government Task） 方面的差异。实际上，PIPL在这两点上并未作出明确规定，这主要归因于中国和欧洲在法律及监管环境上的差异。 首先在 合法利益 这一点上，GDPR作为欧洲地区的人权保护框架，旨在平衡企业与个人之间的权益，为企业提供一定的 灵活性 ，允许其在没有明确同意的情况下处理个人数据，从而在一定程度上增强了企业的自主权。相比之下， PIPL更加强调对个人信息的严格控制。 在处理个人数据时，PIPL要求必须获得明确的授权或依据法律规定进行，更倾向于通过明确同意或法律规定来实施严格监管。 其次在 公共利益 方面，两部法律对公共事务和政府职责的界定存在差异。 GDPR 在确保公共机构履行任务时赋予了更大的 灵活性 ，而PIPL则通过其他法律条款来规范政府的处理权限，更加侧重于 信息透明性和数据主体的保护 。 二、信息跨境处理注意事项 在 跨境处理信息 的过程中，除了需遵循《个人信息保护法》（PIPL）和《通用数据保护条例》（GDPR）这两部基础法律的规定外，还需执行一系列严格的 安全评估措施。 以中国车企为例，若需将欧盟境内的数据传输回中国进行处理，必须确保该跨境数据传输完全符合GDPR的严格要求。 GDPR对向欧盟外传输数据有着明确的规范，要求必须依赖 标准合同条款（SCCs）或充分性决定（Adequacy Decision） 来确保数据的合法传输。特别是当涉及敏感个人信息处理时，如位置数据、行为数据以及测绘数据等，企业可能还需进行 数据保护影响评估（DPIA） ，以全面评估数据处理的合法性、必要性和风险性。 值得注意的是，由于欧盟目前尚未对中国作出充分性决定，因此中国企业在向欧盟外传输数据时，可能需要与相关方签订 标准合同条款（SCCs） 来确保数据传输的合法性。 总之，在跨境传输过程中，为降低数据泄露或不当使用的风险，企业需对敏感数据进行加密或匿名化处理。

自动驾驶汽车安全吗？当代汽车中的软件包含上亿行代码，这些代码使得许多不同的功能得以实现——巡航控制、速度辅助和停车摄像头。且这些嵌入式系统中的代码只会变得更加复杂。 随着未来汽车变得更加互联，汽车逐渐变得更加依赖技术，并且逐渐变得更加自动化——最终实现自动驾驶，了解自动驾驶汽车的安全问题变得非常重要，这样你才能回答“自动驾驶汽车安全吗”和“自动驾驶汽车比人类更安全吗”这样的问题。 Jump to 你喜欢的部分