从今年6月（后了解到具体时间为2021年6月17号）起，开始听到和看到一些文章推送百度跟北汽集团旗下ARCFOX 极狐品牌打造的新一代量产共享无人车Apollo Moon，备感震撼。震撼于其只需要48万的造价；百度Apollo L4无人车已经跟多家车企合作完成前装定制化；“前装量产车”+“AI老司机”+“5G云代驾”，Apollo无安全员自动驾驶的完整RoadMap（智慧的车），尤其是其在智能网联聪明的路上已经在多城市跟政府开展深入合作；Apollo Moon兼容低成本纯视觉方案Apollo Lite，后者已降维至多款车型，提供AVP (Apollo Valet Parking)、ANP (Apollo Navigation Pilot)辅助驾驶功能，实现了泊车域到行车域的跨越，具备全域点到点自动驾驶能力覆盖。
　这一切的布局和成果让我感觉中国的无人驾驶到了一个新局面，一个技术完成初步沉淀，盈利模式开始清晰的阶段。作为从业者，我理解技术上真的还有很多问题待解决，但是现有的技术是能跟满足某些工况下的无人驾驶的，更重要的是只有DEMO，没有实打实的实际应用场景融入迭代，无人驾驶永远只能是DEMO。借助Apollo 4年多开源生态的积累，依托百度、百度AI的品牌和公司号召力，承接中国强大基建能力，百度Apollo，在中国甚至在全世界，其实际应用场景和量产落地化能力都处于领先位置。
　我很好奇，百度 Apollo 是如何一步一步梳理除今天这样的一个RoadMap？Apollo 开源至今都经历了哪些里程碑？跟自己从业特别相关的，Apollo 无人车的Sensor Settings经历了怎样的演变才到Apollo Moon这个第五代硬件方案？通过阅读和梳理近4年（≈自己的从业时间）的资料，主要是官方公众号文章和日常阅读收藏的文章，希望能解答自己的疑问，瞥见一些行业趋势，在有限的时间里做更正确的事情。

　在校包括从业，涉足自动驾驶这个行业也近六载了，工作后也许久没再写过博文了。这一次，想把从业高度相关的，近期梳理的国内自动驾驶头部公司Sensor settings，或者是自动驾驶硬件方案梳理一下，整理成一期系列文章（主要也是内容太多太杂，先用博文整理一下，再看是否有时间浓缩成slides吧）。

ICP 算法简介

• 由点云配准 说起

  　Point cloud registration, is the process of finding a spatial transformation that aligns two point clouds. The purpose is to merge point clouds of multiple views into a globally consistent model.
  　Iterative Closest Points (ICP) is an algorithm employed to minimize the difference between two clouds of points. In the algorithm, target point cloud, is kept fixed, while the other one, the source, is transformed to best match the reference (the target). The algorithm iteratively revises the transformation (combination of translation and rotation) needed to minimize the distance from the source to the reference point cloud.

　　本文介绍在 ROS 的 launch 文件中经常被使用到的三个与参数设置有关的标签 <arg>、<param>、rosparam。

　Boss 自动驾驶软硬件概述。

Overview

• 软件概述
  • Motion planning sub-system
    ==> 2 planners: avoiding static and dynamic obstacles while achieving a desired goal（最终都是产生一条 trajectory）
    • structured driving: road following
    • unstructured driving: maneuvering in parking lots（停车场等的机动控制）
  • Perception sub-system

Abstract

• model-predictIve trajectory generation algorithm（模型预测轨迹生成算法）
• long range plans
  • on-road planning
  • unstructured planning: parking lots/anomalous on-road scenarios（异常路况）

　情况是这样的，在之前讲过的回播 .pcap 数据的 Velodyne_player 程序中，需要调用 Winpcap (其实就是 libpcap 的 Win挫版) 的 API 解析 .pcap 数据，再通过 UDP 发送出去。我们的 Velodyne_player 是一个 Win32 的程序，显然调用的就是32位的 Winpcap 库的 API； 后来我们也移植了一个 .pcap 采集程序的 Linux 版本，结果，用该 Linux 版本采集程序采集到的 .pcap 数据却没办法用我们 Win 下的 Velodyne_player 回播。后来发现，我们的 Linux 版本的采集程序用的是64位的 libpcap 库(因为系统是64位的 Ubuntu16.04，默认安装的就是64位的 libpcap 库)，64位和32位的 libpcap，在时间戳上有很关键的区别，下面是开源的 pcap.h 中的声明:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

/*
 * Generic per-packet information, as supplied by libpcap.
 *
 * The time stamp can and should be a "struct timeval", regardless of
 * whether your system supports 32-bit tv_sec in "struct timeval",
 * 64-bit tv_sec in "struct timeval", or both if it supports both 32-bit
 * and 64-bit applications.  The on-disk format of savefiles uses 32-bit
 * tv_sec (and tv_usec); this structure is irrelevant to that.  32-bit
 * and 64-bit versions of libpcap, even if they're on the same platform,
 * should supply the appropriate version of "struct timeval", even if
 * that's not what the underlying packet capture mechanism supplies.
 */
struct pcap_pkthdr {
  struct timeval ts;	/* time stamp */
  bpf_u_int32 caplen;	/* length of portion present */
  bpf_u_int32 len;	/* length this packet (off wire) */
};

　　To add navigation to a robot, we need to launch 3 nodes:

• map_server: to provide the static map {“*.yaml” & “*.pgm”}, against which the robot will localize and plan.
• amcl: to localize the robot against the static map.
• move_base: to handle global planning and local control for the robot.

　　amcl 是移动机器人二维环境下的概率定位系统，它实现了自适应(或 kdl 采样)的 蒙特卡洛定位 方法，其中针对已有的地图使用 粒子滤波器 跟踪一个机器人的姿态。

　　move_base 提供了 ROS 导航的配置，运行，交互接口，主要包括两个部分：

　(1) 全局路径规划：根据给定的目标位置进行总体路径的规划
　(2) 局部路径规划：根据附近的障碍物信息进行躲避路线规划