之前学习ros，买的nvidia jetson nano板子装的ubuntu系统，pi4的板子装的raspberry系统，最近学习些东西，发现依赖包在ubuntu下apt一键就能安装上，在raspberry上各种依赖很多没有这个系统的库。忘记当初pi4安装ubuntu遇到什么困难了，印象中用官方的ubuntu18.04.5镜像是不行的。这次不偷懒了，记录一下pi4上的环境搭建过程。
在测试ros的slam建图，建好地图使用时，出现一个很诡异的现象：在rviz上里点击”2D Nav Goal”按钮指定目的地时机器人没反应，也没有任何错误日志，像是就没发出去似的。
ROS 机器人的实验和开发中，通常需要一台移动机器人和一台 PC 配合使用，不少初学者都会有个困惑，即PC和机器人上的ROS命令都只针对本机，而机器人上的ubuntu通常都不是桌面版，那么PC上那些可视化的工具怎么应用在机器人上呢？即怎么才能利用PC上的ROS指令和工具直接访问和展示机器人上的数据呢？其实非常简单，通过ROS_MASTER_URI就可以方便的实现，本文我们就来简单介绍一下吧。
近期国家智能网联汽车研究中心及十几家产业链公司联合起草并发布业界首个智能驾驶功能软件平台设计规范，已经详细到接口/信号数据结构定义粒度，将会加速推动自动驾驶汽车软件的规范化。
移动机器人在环境中获取障碍物的具体位置、房间的内部轮廓等信息都是非常必要的，这些信息是机器人创建地图、进行导航的基础数据。考虑成本，买了一个SLAMTEC公司的低成本二维激光雷达RpLidar A1进行初步的学习，它可以最快10hz的频率检测360度范围内的障碍物信息，最远检测距离12米，适合室内移动机器人使用。本文讲解如何使用它感知周围环境。
新入手一个Pi4，4核1.5GHz 64位A72处理器、8G内存（想起我的第一台电脑，赛扬处理器+512M内存…），用来做机器人的控制中心。由于树莓派4暂时还无法使用Ubuntu MATE，本文讲解给它安装Raspberry Pi OS系统 + ROS Melodic的过程。
最近学习ROS，涉及底盘移动等执行机构时，发现买robot套件太贵了，又懒得从pi上直接开发，翻箱倒柜找到一个以前跟儿子一起做的arduino履带坦克，就拿它作ros机器人的action执行机构吧。
简单点说，ROS2与ROS最大的区别就是：
上次我们通过机器人操作系统ROS—初探了解了ROS的基本概念和运行机制，并用内置的小龟模拟器进行了测试。本文我们开始学习如何编写自定义的Service/Client节点进行指定msg格式通信、尝试bag的录制和回放、并简单了解下三维可视化。
温习一下，上一次我们了解到topic里的Message、ROS Services概念：
消息(msg):
msg文件就是一个描述ROS中所使用消息类型的简单文本。它们会被用来生成不同语言的源代码。
一直听到ROS这个名字，很好奇它为什么在机器人领域这么出名，所以从今天起我将从零开始学习一下，看看它到底有哪些神奇之处。本文作为初探篇会先带大家了解ROS的基本概念，通过安装和创建/运行程序包了解Nodes节点、Topics/Msg、Service服务/参数服务器、几个常见的工具。
ROS (Robot Operating System, 机器人操作系统) 提供一系列程序库和工具以帮助软件开发者创建机器人应用软件。它提供了硬件抽象、设备驱动、库函数、可视化、消息传递和软件包管理等诸多功能。ROS遵守BSD开源许可协议。
ROS的官网：https://ros.org/
ROS 图（graph）概念：
Nodes:节点,一个节点即为一个可执行文件，它可以通过ROS与其它节点进行通信。
申请了好久的预算老婆终于批了，入手华硕的GPU本（RTX2070），默认预装了正版win10，平时还是习惯用linux，本文记录了如何安装ubuntu18.4的过程。
目前全球进入人工智能、物联网、自动驾驶、5G的新一轮技术革命浪潮中，深度学习、强化学习技术使计算机在某些特定领域（例如人脸识别、AlphaZero）下实现了比人类更好的效果，物联网促进所有电子设备的互联互通，自动驾驶使汽车更加智能和安全，5G使万物互联成为可能。
很多新技术在现实中的落地应用都避免不了大量的消息实时通信，例如物联网或自动驾驶，要想实时的获取海量设备或车辆的信息并进行远程控制指令下发，频繁的断开连接是无法确保通信效率和可靠性的，尤其是自动驾驶v2x等场景，云端结合路灯、红绿灯、其他车辆的数据判定某辆车必须进行减速以避免事故时，指令下发的时效性和送达率将是致命的问题，另外还有网络信号不稳定、地库等特殊环境信号差等情况，本文将针对这些问题来研究和探讨如何构建一个支持弱网的高送达率、高时效性、高安全性、高传输效率的实时双向/多向消息传输服务。
全国SLAM技术论坛由中国图象图形学学会CSIG主办，每年举办一届，邀请学术界和企业届的专家围绕SLAM技术的研究、发展以及产业化应用作技术分享。本文整理自浙江大学刘勇教授在第二届全国SLAM技术论坛中的报告。
刘勇，浙江大学智能系统与控制研究所教授，浙江大学求是青年学者，浙江省“新世纪151人才工程”第二层次培养人员，担任浙江省机器换人专家组专家。承担NSFC-浙江两化融合联合基金、国家自然科学基金青年和面上项目、科技部863重点项目子课题、浙江省杰出青年基金、工信部重大专项等国家级省部级项目多项。获得浙江省自然科学奖2017（一等奖），科学进步奖2013（一等奖）。主要研究方向包括：智能机器人系统、机器人感知与视觉、深度学习、大数据分析，多传感器融合等。
多源融合SLAM-现状与挑战
SLAM的定义比较经典，它的核心就是一个状态估计问题，根据传感器观测到的数据以及一些实际的模型，如何对这两者进行结合来准确估计实际情况。这个问题虽然在数学模型上比较简单，但是在实际过程中会面临很多的挑战以及不如意的实际现象。
首先的一个挑战就是landmark在实际应用中的复杂性（由于环境的复杂性引起）；其次，由于sensor的不同，也会存在一些其他的问题。具体来讲，在纹理少、四季天气变化、光照剧烈变化、车载条件IMU退化、长走廊、机器人剧烈运动等情况下，原来很好用的SLAM方法在这些情况下往往会无用。这都是很棘手的场景，这些场景会给我们带来实际应用中的困惑，采用单一的传感器会面临这个问题，所以多源融合这个领域很热门，被产业界所认可。
随着自动驾驶技术的发展，在未知环境中智能汽车的定位技术成为该领域研究的核心。目前定位技术主要的解决方案是基于全球定位系统（GPS），但是在某些特殊的环境中如下车库，没有 GPS 信号如何解决定位问题就是本文研究的关键所在。
近年来，同步定位与地图构建（Simultaneous Localization and Mapping，SLAM）技术的日益成熟，配合多传感器融合解决方案，自动驾驶车辆在未知环境无 GPS 信号的情况下，完成路径规划的自动驾驶任务得以实现。本文先介绍了自动驾驶系统概述、视觉激光融合的 SLAM 理论与算法，又基于 ROS 框架搭建了自动驾驶汽车的建图与路径规划仿真实验，最后完成了在地库中的实车算法验证实验，并做了论文结论总结与自动驾驶技术的未来展望。
自动驾驶汽车即无人驾驶智能汽车，在没有人为参与的情况下，依靠车内的控制系统与智能算法，通过多重传感器数据融合控制汽车底层协议完成正常的车辆行驶功能。智能驾驶汽车是一个综合的集成系统，包括了自动泊车系统、自动驾驶系统、障碍物停障系统等，又分为了感知层、决策层和控制层三个部分如图 1 所示。
其中感知层包括各路传感器的数据采集、处理与融合等，更加精确和全面的感知周围环境信息。决策层的输入包括感知层的信息、路径的规划以及控制层反馈回来的数据，通过增强学习算法下发决策指令。决策指令包括了循迹、跟车、超车、刹车、转向、调头等等；最终通过控制层下发 CAN 总线下发指令完成智能驾驶汽车的自动驾驶任务，包括油门与刹车的控制、方向盘与挡位的控制等等。
自动驾驶汽车发展与研发中的核心技术是车辆线控技术和车辆精确定位技术。本论文主要分析车辆的精确定位，目前最常用的解决方法就是使用 GPS，可以让汽车实时地得到自身的位置坐标。本文则基于 SLAM 技术研究了一种新的定位方法。
结合 SLAM 技术，自动驾驶汽车的传感器分别由摄像头、激光雷达、车载毫米波雷达、车载超声波雷达、惯导组合、工业控制器等组成，具体的安装位置如图 2 所示。
我们知道，照相机的原理是将一个三维场景投影到二维平面。所谓视觉三维重建，顾名思义就是从已有的二维图像中复原原始三维场景。
三维重建的原理大致如下：
基于图像的三维重建基本流程
本文简要介绍三维重建的基本流程，列举若干常见系统，给出项目和文档地址，比较它们的工作管线，为深入钻研系统结构作为铺垫。
我们知道，照相机/摄像机的原理是将一个三维场景或物体投影到二维平面上，过去是胶片，现在是经过感光元件再记录到存储器。降维的过程通常不可避免地会存在信息的损失，而所谓的重建(Reconstruction)，顾名思义就是要从获取到的二维图像中复原原始三维场景或物体。
相对照相机的诞生，三维重建的概念本身说年轻也算年轻；但相比从2012年开始比较火的深度学习、神经网络等概念，三维重建也算是古老的研究领域了，因为第一个基于图像的三维重建系统诞生于1992年（CMU的Tomasi等人的工作）。
三维重建的流程大致如下：首先，通过多角度拍摄或者从视频中提取得到一组图像序列，将这些图像序列作为整个系统的输入；随后，在多视角的图像中，根据纹理特征提取出稀疏特征点（称为点云），通过这些特征点估计相机位置和参数；在得到相机参数并完成特征点匹配后，我们就可以获得更稠密的点云（这些点可以附带颜色，从远处看就像还原了物体本身一样，但从近处能明显看出它们只是一些点）；最后根据这些点重建物体表面，并进行纹理映射，就还原出三维场景和物体了。
概括起来就是：图像获取->特征匹配->深度估计->稀疏点云->相机参数估计->稠密点云->表面重建->纹理映射
目前已有不少免费系统（部分系统已开源）能够完成三维重建的整个流程，在深入研读某一个系统的代码之前，我决定先根据前人资料横向比较一下这些系统的异同。除了亲自运行了几个系统外，主要参考了这个视频的讲解（需要科学上网），以下内容的部分截图也出自这里。感谢视频原作者和以下每个系统的创造者。
图中从左至右的过程依次是从原始图像到稀疏点云、重建稠密点云、重建表面和纹理映射。对应列的绿色代表该系统具备此功能，红色反之。
数字视频的超高清潮流奔腾向前，帧率从30 fps向60fps、120fps甚至240fps进发，与此同时，物理媒介日薄西山，内容正通过有形无形的网络在世界各个角落的终端设备上传递。高度密集的数据给带宽和存储带来巨大挑战，当前主流的H.264开始不敷应用，而新一代视频编码标准H.265似乎成为了数字4K时代的“救世主”。
H.265又称为HEVC(全称High Efficiency Video Coding，高效率视频编码，本文统称为H.265)，是ITU-T H.264/MPEG-4 AVC标准的继任者。2004年由ISO/IEC Moving Picture Experts Group(MPEG)和ITU-T Video Coding Experts Group(VCEG)作为ISO/IEC 23008-2 MPEG-H Part 2或称作ITU-T H.265开始制定。第一版的HEVC/H.265视频压缩标准在2013年4月13日被接受为国际电信联盟(ITU-T)的正式标准。
理论上H.265比H.264效率提高30-50%(尤其是在更高的分辨率情形下)，但真的只是这么简单吗？
汽车功能安全中的有些概念比较绕，比如故障(fault)，错误(error)，失效(failure)，今天就这三个概念进行下探讨。
功能安全中定义的故障是指可引起要素或相关项失效的异常情况。
故障可以分为永久故障和非永久故障，其分类如下图所示。
永久性故障是指发生并持续，直到被移除或修复的故障。也就是说永久性故障发生了必须采取相应的措施才能够使其恢复其正常运行。其中系统性故障一般表现为永久性故障。
非永久性故障可以分为间歇性故障和瞬态故障。间歇性故障是指故障一再的发生，然后消失。当一个组件处于损坏的边缘时，或者例如由于开关的电涌（电压的瞬态激烈变化），间歇性故障可能会发生。某些系统性故障（例如时序混乱）也可能导致间歇性故障。
瞬态故障是指发生一次且随后消失的故障。瞬态故障可由电磁干扰引起，其可导致位翻转。比如由于单粒子翻转效应(SEU)和单粒子瞬态脉冲(SET)发生的软错误，均为瞬态故障。（单粒子翻转是宇宙中单个高能粒子射入半导体器件灵敏区，使器件逻辑状态翻转的现象。）
ISO 26262中定义的错误是指计算的、观测的、测量的值或条件与真实的、规定的、理论上正确的值或条件之间的差异。错误可由未预见的工作条件引起或由所考虑的系统、子系统或组件的内部故障引起。故障可表现为所考虑要素内的错误，该错误可最终导致失效。
比如由于宇宙中单个高能粒子射入半导体器件灵敏区，使存储器逻辑状态翻转的单粒子翻转效应SEU，使得软件中某个bit位从0到1或者从1变成0是属于一个软错误（硬件没有损害）。
从上可以看出故障，错误和失效的大概关系是故障可引起错误，错误再导致失效。下文会再做详细说明。
失效，按照ISO26262的定义是要素按要求执行功能的能力的终止。（英文：terminationof the ability of an element to perform a function as required）
注：不正确的规范是失效的来源之一。
在这里失效针对的是功能的丧失或者终止。比如对于电机控制器来说，其主要的功能之一是根据整车控制器VCU的扭矩请求，对电机进行转矩和转速的控制，因此无论输出的扭矩非预期的偏大或者偏小都是一种失效。
在功能安全中依据失效的原因可以分为两种：系统性失效和随机硬件失效。ISO 26262的主要目的就是尽可能的消除这两类失效。
（1）系统性失效（systematic failure）
以确定的方式与某个原因相关的失效，只有对设计或生产流程、操作规程、文档或其它相关因素进行变更后才可能排除这种失效。
系统性失效存在三个特征：
A- 仅仅进行正确维护而不加修改的情况下，无法消除故障。
B-通过模拟失效原因可以使其重复出现。
C-是人为错误引起，失效原因比如：安全要求规范的错误；硬件的设计，制造，安装，操作的错误；软件的设计和实现的错误等。
软件故障和部分的硬件故障是属于系统性故障。比如coding的时候没有考虑使用数据类型的错误，某变量（比如精度为1，offset为0）本应该使用U16的，结果用成了U8，使得计算的最大数值只能到255。这里的软件bug是属于系统性失效。
（2）随机硬件失效（random hardware failure）
按照ISO 26262的定义，随机硬件失效是在硬件要素的生命周期中，非预期发生并服从概率分布的失效。并且可在合理的精度范围内进行预测。
非预期发生的含义是尽管硬件的设计是正确的，比如电子元器件的选型，电阻值，电容值，电路设计等都是正确的，且器件是符合质量标准的。但是却无法预知在哪里发生，以怎样的形式发生的失效。
服从概率分布的含义是失效可以在合理的精度范围内进行预测。比如通过可靠性或者分析得到失效率。
随机硬件失效的起因是由于物理过程，比如疲劳、物理退化或环境应力等。比如上面提到的位翻转，比如电阻的开路，短路，阻值漂移等等。
此外功能安全中还定义了相关失效和非相关失效。
相关失效是指失效同时或相继发生的概率不能表示为每个失效无条件发生概率的简单乘积。比如当失效A和失效B同时发生的概率不等于两个失效概率的乘机，用数学关系式表示为Pab =Pa*Pb，失效A和B可被定义为相关失效。反之非相关失效可以表示为每个失效无条件发生概率的简单乘积。
相关失效可以分为共因失效和级联失效。
共因失效是指在相关项中，有一个单一特定事件或根源引起的两个或多个要素的失效。如下图所示。
通过多样化的程序和硬件设计可以避免共因失效。
级联失效是指同一个相关项中，一个要素的失效引起另一个或者多个要素的失效。
比如软件的分区可以避免级联失效。实际应用过程中将level1和level2中的变量存储在不同的RAM区或NVRAM区就是一种分区的方式。
硬件故障按照故障类型可以分为如下几种，如下图所示：
（1）安全故障：
安全故障是指某个故障的发生不会显著的增加违反安全目标的概率（ISO 26262）。安全故障可以分为两类：
a) 与安全目标违背无关的故障。
在万物联网的时代，安全问题将会受到非常严峻的挑战（相应地，也会获得最大的关注度），因为我们身边的每一个IOT设备，都是一个处于封印状态的天眼，随时都有被开启的危险。想想下面的场景吧：
凌晨2点，x米手环的闹钟意外启动，将你从睡梦中惊醒，然后床头的灯光忽明忽暗……
你的心率、血压、睡眠质量等信息，默默地被竞争对手收集着，并通过大数据分析你的情绪、健康等，随时准备给你致命一击……
我知道你家里有几盏灯、几台电器、几个人，知道你几点睡觉几时醒来，知道你一周做过几顿饭，甚至知道你有一个xx棒、一周使用几次、每次使用多久……
……算了，不罗列了，有时间的话可以建个iot eyes的站点，专门收集、整理物联网安全有关的内容。这里就先言归正传。
经过前面几篇的蓝牙协议分析，我们对蓝牙（特别是蓝牙低功耗）已经有了一个比较全面的了解。随后几篇文章，我会focus在BLE的安全机制上。毕竟，知己知彼，才能攻防有度。
话说，蓝牙SIG深知物联网安全的水有多深，因此使用了大量的篇幅，定义BLE安全有关的机制，甚至可以不夸张的说，BLE协议中内容最多、最难理解的部分，非安全机制莫属。本文先从介绍最简单的—-白名单机制（White list）。
白名单（white list）是BLE协议中最简单、直白的一种安全机制。其原理很简单，总结如下（前面的分析文章中都有介绍）：
所谓的白名单，就是一组蓝牙地址；
通过白名单，可以只允许特定的蓝牙设备（白名单中列出的）扫描（Scan）、连接（connect）我们，也可以只扫描、连接特定的蓝牙设备（白名单中列出的）。例如，如果某个BLE设备，只需要被受信任的某几个设备扫描、连接，我们就可以把这些受信任设备的蓝牙地址加入到该设备的白名单中，这样就可以有效避免其它“流氓设备”的骚扰了。
不过呢，该机制只防君子不防小人，因为它是靠地址去过滤“流氓”的，如果有些资深流氓，伪装一下，将自己的设备地址修改为受信任设备的地址，那就惨了……
注1：本文主要从HCI的角度分析、介绍，如非必要，不再会涉及HCI之下的BLE协议（后续的分析文章，也大抵如此）。
BLE协议在HCI层定义了4个和白名单维护有关的命令，分别如下：
1）LE Read White List Size Command，获取controller可保存白名单设备的个数
该命令的格式为：
| OCF | Command parameters | Return Parameters |
| 0x000F | Status White_List_Size |
Status，命令执行的结果，0为success。
White_List_Size，size，范围是1～255。注2：由此可知，白名单是保存在controller中，由于size的范围是1～255，因此controller必须实现白名单功能（最少保存一个）。
2）LE Clear White List Command，将controller中的白名单清空
该命令的格式为：
| OCF | Command parameters | Return Parameters |
| 0x0010 | Status |
Status，命令执行的结果，0为success。3）LE Add Device To White List Command，将指定的设备添加到白名单
该命令的格式为：
| OCF | Command parameters | Return Parameters |
| 0x0011 | Address_type(1 byte) Address(6 bytes) |
Status |
Address_type，设备的地址类型[1]，0为Public Device Address，1为Random Device Address。
Address，设备的地址。
Status，命令执行的结果，0为success。4）LE Remove Device From White List Command，将指定的设备从白名单中移除的命令
该命令的格式为：
| OCF | Command parameters | Return Parameters |
| 0x0012 | Address_type(1 byte) Address(6 bytes) |
Status |
Address_type，设备的地址类型[1]，0为Public Device Address，1为Random Device Address。
Address，设备的地址。
Status，命令执行的结果，0为success。最后需要说明的是，当controller处于以下三个状态的时候，以上命令除“LE Read Resolving List Size Command”外，均不能执行：
正在advertising；
正在scanning；
正在connecting。BLE设备在发起Advertising、Scanning或者Connecting操作的时候，可以通过Set Advertising Parameters、Set Scan Parameters或者LE Create Connection Command，设置Advertising、Scanning或者Connecting的过滤策略（Filter_Policy），具体如下：
1）Advertising时的白名单策略
LE Set Advertising Parameters Command的命令格式为：
| OCF | Command parameters | Return Parameters |
| 0x0006 | … Advertising_Filter_Policy(1 byte) |
Status |
该命令的其它参数请参考[2]，Advertising_Filter_Policy的含义如下：
0x00，禁用白名单机制，允许任何设备连接和扫描。
0x01，允许任何设备连接，但只允许白名单中的设备扫描（scan data中有敏感信息？）。
0x02，允许任何设备扫描，但只允许白名单中的设备连接。
0x03，只允许白名单中的设备扫描和连接。2）Scanning时的白名单策略
LE Set Scan Parameters Command的命令格式为：
| OCF | Command parameters | Return Parameters |
| 0x000B | … Scanning_Filter_Policy(1 byte) |
Status |
该命令的其它参数请参考[2]，Scanning_Filter_Policy的含义如下：
0x00，禁用白名单机制，接受所有的广播包（除了那些不是给我的directed advertising packets）。
0x01，只接受在白名单中的那些设备发送的广播包（除了那些不是给我的directed advertising packets）。
0x02，和白名单无关，不再介绍。
0x03，接受如下的广播包：在白名单中的那些设备发送的广播包；广播者地址为resolvable private address的directed advertising packets；给我的给我的directed advertising packets。注3：Scanning时的白名单策略有点奇怪，既然是主动发起的，要白名单的意义就不大了吧？难道只为了减少host的响应耗电？
3）Connecting时的白名单策略
LE Create Connection Command的命令格式为：
| OCF | Command parameters | Return Parameters |
| 0x000D | … Initiator_Filter_Policy(1 byte) … |
Status |
该命令的其它参数请参考[4]，Initiator_Filter_Policy的含义如下：
0x00，禁用白名单机制，使用Peer_Address_Type and Peer_Address指定需要连接的设备。
0x01，连接那些在白名单中的设备，不需要提供Peer_Address_Type and Peer_Address参数。后续的测试需要用到如下的设备和软件：
1）蓝牙设备A，作为Advertiser，发送广播数据，接受连接。
2）蓝牙设备B，作为Scanner，扫描设备A的广播数据，发起连接。
上述的1）和2）可以是如下一种：
一个具有bluez（hcitool等工具）的Android手机，可能需要较旧的android版本才行；
带有蓝牙功能的树莓派，允许Debian、Ubuntu等系统（只要不是Android就行）；
Linux PC（或者虚拟机）加上一个具有BLE功能的蓝牙适配器。3）bluez工具集，我们需要使用其中的hcitool命令。
hcitool中的一些命令，和白名单机制有关，总结如下。
1）hcitool lewlsz，获取controller白名单的size，对应3.1中的LE Read White List Size Command，该命令不需要参数，可直接使用，如下：
root@android:/ # hcitool lewlsz
hcitool lewlsz
White list size: 262）hcitool lewlclr，情况controller的白名单，对应3.1中的LE Clear White List Command，该命令也不需要参数，可直接使用，如下：
root@android:/ # hcitool lewlclr
hcitool lewlclr3）hcitool lewladd，将指定设备添加到白名单中，对应3.1中的LE Add Device To White List Command，其格式如下：
root@android:/ # hcitool lewladd --help
hcitool lewladd --help
Usage:
lewladd [--random]其中是必选项，为要添加的蓝牙设备的地址。地址有public和random两种，默认是public，如果需要添加random类型的地址，则要指定–random参数，例如：
root@android:/ # hcitool lewladd 22:22:21:CD:F4:58
hcitool lewladd 22:22:21:CD:F4:58
root@android:/ # hcitool lewladd --random 11:22:33:44:55:66
hcitool lewladd --random 11:22:33:44:55:664）hcitool lewlrm，将指定设备从白名单中移除，对应3.1中的LE Remove Device From White List Command，该命令只需要蓝牙地址作为参数，如下：
root@android:/ # hcitool lewlrm --help
hcitool lewlrm --help
Usage:
lewlrm5）hcitool lecc，连接BLE设备的命令，对应3.2中的LE Create Connection Command，可以连接指定地址的设备，也可以直接连接白名单中的设备：
root@android:/ # hcitool lecc --help
hcitool lecc --help
Usage:
lecc [--random]
lecc --whitelist一般情况下，我们都是通过hcitool lecc 的方式连接蓝牙设备，不过如果我们需要连接白名单中的设备，可直接使用如下命令：
hcitool lecc --whitelist6）hcitool cmd，对于其它没有直接提供hcitool命令的HCI操作，我们可以使用hcitool cmd直接发送命令，其使用方法如下：
root@android:/ # hcitool cmd --help
hcitool cmd --help
Usage:
cmd [parameters]
Example:
cmd 0x03 0x0013 0xAA 0x0000BBCC 0xDDEE 0xFF其中ogf、ocf和parameters可以去蓝牙spec的“HCI COMMANDS AND EVENTS”章节查询。需要注意的是，parameters可以使用各种类型（8位、16位、32位），还是很方便的。
这里仅仅罗列一个简单的测试，步骤包括：
1）设备A作为Advertising设备，不使用白名单，发送正常的ADV_IND（可连接、可扫描）广播包。
2）设备B扫描并连接设备A（应该可以正常连接）。
3）设备A作为Advertising设备，启用白名单，设置Advertising_Filter_Policy为0x2(只允许白名单中的设备连接)，且没有把B的地址添加到白名单中。
4）设备B扫描并连接设备A（应该不可以正常连接）。
5）设备A把设备B添加到白名单中，其它策略保持不变。
6）设备B扫描并连接设备A（应该可以正常连接）。详细步骤如下（我没有测试，有问题的请大家留言告诉我）：
1）设备A作为Advertising设备，不使用白名单，发送正常的ADV_IND（可连接、可扫描）广播包。
# disable BLE advertising
hcitool cmd 0x08 0x000A 0x00
# 设置广播参数和广播策略
# Advertising_Interval_Min=0x0800 (1.28 second, default)
# Advertising_Interval_Max=0x0800 (1.28 second, default)
# Advertising_Type=0x00(ADV_IND, default)
# Own_Address_Type=0x00(Public Device Address, default)
# Peer_Address_Type=0x00(Public Device Address, default)
# Peer_Address=00 00 00 00 00 00 (no use)
# Advertising_Channel_Map=0x07(all channels enabled, Default)
# Advertising_Filter_Policy=0x0(禁用白名单)
hcitool -i hci0 cmd 0x08 0x0006 0x0800 0x0800 0x00 0x00 0x00 00 00 00 00 00 00 0x07 0x00
# enable BLE advertising
hcitool cmd 0x08 0x000A 0x01
# set advertising data to Eddystone UUID(可参考[3]中的介绍)
hcitool -i hci0 cmd 0x08 0x0008 1e 02 01 06 03 03 aa fe 17 16 aa fe 00 -10 00 01 02 03 04 05 06 07 08 09 0a 0b 0e 0f 00 00 00 002）设备B扫描并连接设备A（应该可以正常连接）。
hcitool lescan
hcitool lecc [bdaddr of A]3）设备A作为Advertising设备，启用白名单，设置Advertising_Filter_Policy为0x2(只允许白名单中的设备连接)，且没有把B的地址添加到白名单中。
# disable BLE advertising
hcitool cmd 0x08 0x000A 0x00
# 设置广播参数和广播策略
# …
# Advertising_Filter_Policy=0x2(只允许白名单中的设备连接)
hcitool -i hci0 cmd 0x08 0x0006 0x0800 0x0800 0x00 0x00 0x00 00 00 00 00 00 00 0x07 0x02
# 清空白名单
hcitool lewlclr
# 随便加一个地址到白名单
hcitool lewladd 11:22:33:44:55:66
# enable BLE advertising
hcitool cmd 0x08 0x000A 0x01
# set advertising data to Eddystone UUID(可参考[3]中的介绍)
hcitool -i hci0 cmd 0x08 0x0008 1e 02 01 06 03 03 aa fe 17 16 aa fe 00 -10 00 01 02 03 04 05 06 07 08 09 0a 0b 0e 0f 00 00 00 004）设备B扫描并连接设备A（应该不可以正常连接）。
hcitool lescan
hcitool lecc [bdaddr of A]5）设备A把设备B添加到白名单中，其它策略保持不变。
# disable BLE advertising
hcitool cmd 0x08 0x000A 0x00
# 设置广播参数和广播策略
# …
# Advertising_Filter_Policy=0x2(只允许白名单中的设备连接)
hcitool -i hci0 cmd 0x08 0x0006 0x0800 0x0800 0x00 0x00 0x00 00 00 00 00 00 00 0x07 0x02
# 将B添加到白名单中
hcitool lewladd [bdaddr of B]
# enable BLE advertising
hcitool cmd 0x08 0x000A 0x01
# set advertising data to Eddystone UUID(可参考[3]中的介绍)
hcitool -i hci0 cmd 0x08 0x0008 1e 02 01 06 03 03 aa fe 17 16 aa fe 00 -10 00 01 02 03 04 05 06 07 08 09 0a 0b 0e 0f 00 00 00 006）设备B扫描并连接设备A（应该可以正常连接）。
hcitool lescan
hcitool lecc [bdaddr of A]在上文中介绍了BLE的白名单机制，这是一种通过地址进行简单的访问控制的安全机制。同时我们也提到了，这种安全机制只防君子，不防小人，试想这样一种场景：
A设备表示只信任B、C、D设备，因此就把它们的地址加入到了自己的白名单中，表示只愿意和它们沟通。与此同时，E设备对它们的沟通非常感兴趣，但A对自己不信任啊，肿么办？
E眼珠子一转，想出一个坏主意：把自己的地址伪装成成B、C、D中任意一个（这个还是很容易办到的，随便扫描一下就得它们的地址了）就行了，嘿嘿嘿！那么问题来了，怎么摆脱“小人E“的偷听呢？不着急，我们还有手段：“链路层的Privacy（隐私）机制”。
总结来说，LL Privacy机制是白名单（white list）机制的进阶和加强，它在白名单的基础上，将设备地址转变成Private addresses[2]地址，以降低“小人E“窃得设备地址进而进行伪装的概率。
从白名单的角度看，Non-resolvable private address和Public Device Address/Static Device Address没有任何区别，因此LL Privacy机制主要指Resolvable Private Addresses。因此，LL Privacy机制的本质是：
通过Resolvable Private Addresses，将在空中传输的设备地址加密，让“小人E”无法窃得，从而增加其伪装的难度。注1：当然，LL Privacy机制可以脱离白名单机制单独使用，不过这样的话好像没什么威力。
注2：有关Resolvable Private Addresses、Identity Address、IRK（Local/Peer IRK）等概念的详细介绍，可参考“蓝牙协议分析(6)_BLE地址类型[2]”，本文将会直接使用。
和白名单机制上的White List类似，如果设备需要使用LL Privacy机制，则需要在Controller端保存一个Resolving List，其思路为：
1）BLE设备要按照[1]中的介绍，配置并使能白名单机制，把那些受信任设备的地址（这里为Identity Address）加入到自己的白名单中，并采用合适的白名单策略。
2）如果设备需要使用LL Privacy策略，保护自己（以及对方）的地址不被窃取，则需要将自己（local）和对方（peer）的地址和加密key保存在一个称作Resolving List的列表中。
3）Resolving List的每一个条目，都保存了一对BLE设备的key/address信息，其格式为：Local IRK | Peer IRK | Peer Device Identity Address | Address Type。
Local IRK，本地的IRK，用于将本地设备的Identity Address转换为Resolvable Private Address。可以为0，表示本地地址直接使用Identity Address；
Peer IRK，对端的IRK，用于将对端设备的Resolvable Private Address解析回Identity Address。可以为零，表示对端地址是Identity Address；
Peer Device Identity Address、Address Type，对端设备的Identity Address及类型，用于和解析回的Identity Address进行比对。4）Resolving List是Host通过HCI命令提供给Controller的，Controller的LL负责如下事项：
发送数据包[3]时：
如果有AdvA需要填充，则判断Resolving List是否有非0的Local IRK，如果有，则使用Local IRK将Identity Address加密为Resolvable Private Address，填充到AdvA中。否则，直接填充Identity Address；
同理，如果有InitA需要填充，则判断Resolving List是否有匹配的、非0的Peer IRK，如果有，则使用Peer IRK将对端的Identity Address加密为Resolvable Private Address，填充到InitA中。否则，直接填充Identity Address。
接收数据包时：
如果数据包中的AdvA或者InitA为普通的Identity Address，则直接做后续的处理；
如果它们为Resolvable Private Address，则会遍历Resolving List中所有的“IRK | Identity Address”条目，使用IRK解出Identity Address和条目中的对比，如果匹配，则地址解析成功，可以做进一步处理。如果不匹配，且使能了白名单/LL Privacy策略，则会直接丢弃。5）需要重点说明的是，Controller和Host之间所有的事件交互（除了Resolving List操作之外），均使用Identity Address。也就是说，设备地址的加密、解密、比对等操作，都是在controller中完成的，对上层实体（HCI之上）是透明的。
结合上面2章的解释，罗列一下LL Privacy策略有关的使用场景（大部分翻译自蓝牙spec）。
由[3]中的介绍可知，处于广播状态的BLE设备，根据需要可发送ADV_IND、ADV_DIRECT_IND、ADV_NONCONN_IND和ADV_SCAN_IND 4种类型的广播包，也就是说有4种不同的广播状态，它们的LL privacy策略有稍微的不同，下面分别描述。
1）ADV_IND
设备（Advertiser）发送ADV_IND时，其PDU（connectable undirected advertising event PDU）有一个AdvA字段，该字段的填充策略为（由controller的LL执行）：
检查Resolving List，查看是否存在非0的Local IRK条目，如果有，则使用Local IRK将自己的Identity Address加密为Resolvable Private Addresses，并填充到AdvA中。否则，直接使用Identity Address。Advertiser收到连接请求时，请求者的地址会包含在PDU的InitA中，该字段的解析策略为（由controller的LL执行）：
如果InitA是Resolvable Private Addresses，且当前使能了地址解析功能，LL会遍历Resolving List中所有的“Peer IRK | Peer Device Identity Address | Address Type”条目，使用Peer IRK解析出Identity Address后和Peer Device Identity Address做比对，如果匹配，则解析成功，再基于具体的白名单策略，觉得是否接受连接；
如果解析不成功，则无法建立连接；
如果InitA不是Resolvable Private Addresses，则走正常的连接过程。Advertiser收到扫描请求时，对ScanA的处理策略，和InitA类似。
2）ADV_DIRECT_IND
设备（Advertiser）发送ADV_DIRECT_IND 时，其PDU（connectable directed advertising event PDU）包含AdvA和InitA两个地址，它们填充策略为（由controller的LL执行）：
检查Resolving List，查看是否存在非0的Local IRK条目，如果有，则使用Local IRK将自己的Identity Address加密为Resolvable Private Addresses，并填充到AdvA中。否则，直接使用Identity Address；
检查Resolving List，查看是否存在非0、和InitA的Identity Address匹配的Peer IRK条目，如果有，则使用Peer IRK将InitA的Identity Address加密为Resolvable Private Addresses，并填充到InitA中。否则，直接使用Identity Address。Advertiser收到连接请求时，请求者的地址会包含在PDU的InitA中，该字段的解析策略为和上面ADV_IND类似，不再详细说明。
3）ADV_NONCONN_IND and ADV_SCAN_IND
这两个状态下，AdvA的填充策略和上面1）和2）一样，不再详细说明。
当Advertiser收到SCAN请求时，对ScanA的处理策略，和1）中InitA类似，不再详细说明。
处于Scanning状态的设备（Scanner）在接收到Advertiser发送的scannable的广播包时，需要按照4.1中解析InitA的方法，解析广播包中的AdvA，并根据当前的白名单策略，进行过滤。
Scanner发送scan请求时，需要指定ScanA和AdvA两个地址。其实ScanA的填充策略和4.1中的AdvA类似，不再详细说明。而AdvA，需要和接收到的广播包的AdvA完全一样，不能有改动。
处于Initiating状态的设备（Initiator）在接收到Advertising发送的connectable的广播包时，需要按照4.1中解析InitA的方法，解析广播包中的AdvA，并根据当前的白名单策略，进行过滤。
同理，Initiator发送连接请求时，需要指定InitA和AdvA两个地址。其实InitA的填充策略和4.1中的AdvA类似，不再详细说明。而AdvA，需要和接收到的广播包的AdvA完全一样，不能有改动。
最后，Initiator在接收到Advertising发送的directed connectable广播包时，除了要解析AdvA，如果InitA是Resolvable Private Addresses，则需要使用Local IRK解析InitA。
[8] Core_v4.2.pdf
摘自:
自1994年由爱立信推出至今，蓝牙技术已经走过了20个岁月。从最初的Bluetooth V1.0，到Bluetooth V4.0（最新的为V4.1，2013年底发布），经历了近9个版本的修订后，发展为当前的状况。
说实话，如今的蓝牙4.1，简直是一个大杂烩：BR/EDR沿用旧的蓝牙规范；LE抄袭802.15.4；AMP直接使用802.11。而这一切的目的，就是以兼容性和易用性为基础，在功耗和传输速率之间左右为难。蜗蜗以为，这并不是优雅的设计。
不过没关系，存在即合理。因此蜗蜗就开出了这样一个专题，希望能够将蓝牙技术上上下下的知识，整理出来，以便在加深自己对蓝牙技术的理解的同时，能够给从事蓝牙相关工作的读者一点启发。
本文是这个专题的第一篇文章，主要基于蓝牙4.1规范（Core_V4.1.pdf），描述蓝牙技术的基本概念。
蓝牙协议包括两种技术：Basic Rate（简称BR）和Low Energy（简称LE）。这两种技术，都包括搜索（discovery）管理、连接（connection）管理等机制，但它们是不能互通的！这也是蜗蜗抱怨蓝牙协议不优雅的原因之一。
厂商要么实现这两种技术中的一种，这时就只能和同样实现了这个技术的设备互通，而不能和实现另外一种技术的设备互通。如果厂商要确保能和所有的蓝牙设备互通，那么就只能同时实现两种技术，而不去管是否真的需要，这样就能碰到什么人说什么话了！
2.1.1 Basic Rate(BR)
Basic Rate是正宗的蓝牙技术，可以包括可选（optional）的EDR（Enhanced Data Rate）技术，以及交替使用的（Alternate）的MAC（Media Access Control）层和PHY层扩展（简称AMP）。说着真拗口，不过通过背后的应用场景，就好理解了：
蓝牙诞生之初，使用的是BR技术，此时蓝牙的理论传输速率，只能达到721.2Kbps。在那个年代，56Kbps的Modem就是高大上了，这个速度可以说是惊为天人了啊！但是科技变化太快了，BR技术转眼就过时了。那怎么办呢？缝缝补补一下，增强速度呗，Enhanced Data Rate就出现了。
使用EDR技术的蓝牙，理论速率可以达到2.1Mbps。这一次的升级换代，还算优雅，因为没有改变任何的硬件架构、软件架构和使用方式上的改变。
也许你也猜到了，EDR又落伍了，看看人家WIFI（WLAN），几十Mbps，上百Mbps，咱们才2.1Mbps，也太寒酸了吧！那怎么办呢？蓝牙组织想了个坏主意：哎，WIFI！把你的物理层和MAC层借我用用呗！这就是AMP（Alternate MAC and PHY layer extension）。艾玛，终于松口气了，我们可以达到54Mbps了。
不过呢，由于蓝牙自身的物理层和AMP技术差异太明显了，这次扩展只能是交替使用（Alternate）的，也就是说，有我（BR/EDR）没你（AMP）。嗯！不优雅！
埋个问题：只能交替使用，那它们怎么切换呢？蜗蜗会在后续的内容中，根据主流蓝牙芯片的解决方案，来探讨一下该问题。
【注1：细心的读者可能会注意到，这里特别强调了optional和alternate这两个字眼，这是蓝牙Spec的原话。它意味着，BR和EDR是可以同时存在的，但BR/EDR和AMP只能二选一。】
2.1.2 Low Energy（LE）
上面所讲的BR技术的进化路线，就是传输速率的加快、加快、再加快。但能量是守恒的，你想传的更快，代价就是消耗更多的能量。而有很多的应用场景，并不关心传输速率，反而非常关心功耗。这就是Bluetooth LE（称作蓝牙低功耗）产生的背景。
LE技术相比BR技术，差异非常大，或者说就是两种不同的技术，凑巧都加一个“蓝牙”的前缀而已。后面我们会详细的解释这种差异，以及LE的行为特征。
蓝牙系统的组成，涉及到Bluetooth Application、Bluetooth Core、Bluetooth Host、Bluetooth Controller等词汇，不知道是因为对英文理解的歧义，还是因为蓝牙规范本身定义的歧义，蜗蜗理解这些词汇时感觉有点别扭。因此特意在这个章节中，对相关概念及其背后的意义进行说明。
上图描述了蓝牙系统的组成， 我们需要注意如下特点：
1）图中所描述的蓝牙系统的组成部分，如Bluetooth Core和Bluetooth Application，如Host和Controller，都是指“逻辑实体”。所谓的“逻辑实体”，需要和日常生活中的“物理实体”区隔开。如在做电路设计时，一个蓝牙芯片、一个主控CPU，就是指物理实体。而蓝牙协议所描述的这些“逻辑实体”，不一定会和物理实体一一对应，如在实际应用中，Host和Bluetooth Application可能会位于同一个物理实体中（主控CPU），而Controller单独位于另一个物理实体中（蓝牙芯片）。
2）蓝牙协议规定了两个层次的协议，分别为蓝牙核心协议（Bluetooth Core）和蓝牙应用层协议（Bluetooth Application）。蓝牙核心协议关注对蓝牙核心技术的描述和规范，它只提供基础的机制，并不关心如何使用这些机制；蓝牙应用层协议，是在蓝牙核心协议的基础上，根据具体的应用需求，百花齐放，定义出各种各样的策略，如FTP、文件传输、局域网等等。
3）Bluetooth Core由两部分组成，Host和Controller。这两部分在不同的蓝牙技术中（BR/EDR、AMP、LE），承担角色略有不同，但大致的功能是相同的。Controller负责定义RF、Baseband等偏硬件的规范，并在这之上抽象出用于通信的逻辑链路（Logical Link）；Host负责在逻辑链路的基础上，进行更为友好的封装，这样就可以屏蔽掉蓝牙技术的细节，让Bluetooth Application更为方便的使用。
4）在一个系统中，Host只有一个，但Controller可以一个，也可以有多个。如：单独的LE Controller；单独的BR/EDR Controller；单独的LE+BR/EDR Controller；在单独的BR/EDR Controller或LE+BR/EDR Controller基础上，增加一个或多个额外的AMP Controller。
【注2：有关Bluetooth Core的详细描述，蜗蜗会在下一篇文章中描述，本文就不再深入介绍了。】
3. BR/EDR vs LE vs AMP
我们先从下面图片对BR/EDR、AMP和BLE三种技术有些更进一步的认识（点击这里可以查看放大后的原图）：
该图片是对Bluetooth Core的一个Overview，从RF的Physical Channel，到Baseband的Physical Link、Logical Link、LMP、L2CAP等概念，都有一些粗略的介绍。由该图片可以看出，BR/EDR、AMP、BLE等技术有如下的特点：
1）BR/EDR技术，过于侧重“点对点”通信，以至于虽然在协议的底层（如Logical Link）有提及多播（Unidirectional）和广播（Broadcast）的概念，但在上层的应用场景中，几乎不存在（也不可能存在）相应的应用。
2）但随着物联网的发展，业界对简单的、不需要连接的多播或广播通信的需求越来越迫切，因此BLE技术在RF和Baseband的协议中，就做出了修改，以适应这种需求，即：修改原有的79个channel的跳频方式，将channel的个数减少为40个，并保留了不少于3个的固定channel，用于广播通信。为仅仅在剩下的37个data channel上跳频。
3）正因为这种改变，原有的搜索/连接/配对等概念，在BLE上就不再存在了，取而代之的是Advertisor、Initiator等概念。但在之后的数据通信的层次上，尽量保持了一致。
4）对于AMP来说，是基于BR/EDR的controller，在完成通常的点对点连接之后，两个蓝牙设备商议，是否需要将后续的数据通信，转移至AMP controller上。这就是Bluetooth 3.0引入的AMP技术。
我们暂时在这篇文章中对蓝牙技术做一个感性认识，在后续的文章中，会基于各个层次的协议，一步一步展开、推进，争取能把蓝牙技术分析透彻。
摘自：http://www.wowotech.net/bluetooth/bt_overview.html