DAY3：传感器1、      截图需要有华为云账号2、      需要有传感器数据采集代码3、      需要编译成功完成时间：2020.5.28 12:00 am请注意：直播进行答疑，学习过程中有任何问题，请在答疑帖中提出，我们会在直播中一一答疑。

小熊开发板的智能烟雾报警器web应用开发的烟感管理的烟雾浓度监控为什么没有数据啊，怎么办

这样可以作为传感器选型的一个参考，减少一些选型适配的时间。

RT

走过路过不要错过，《MDC传感器适配》专栏正式开通，欢迎广大朋友们发帖庆祝~~~

一、多传感器融合定位介绍高精度定位是智能网联驾驶的核心基础功能之一，现有的定位方式以使用GNSS服务为主，包括采用GPS差分技术的RTK、或架设临时基站等方式；此外还有蜂窝定位技术、针对限定场景的物联网定位技术以及基于激光雷达的反向定位技术等。其中GNSS定位技术应用最广，但在精度和可靠性上无法满足高精定位的需要，在遇到GNSS信号丢失或遮挡等情况时无论是架设基站还是采用RTK均无法达到智能网联汽车的车道级定位要求；而限定场景的物联网定位技术面临着设备安装改造和维护的问题，其成本庞大无法面对开放道路，应用场景有限；蜂窝定位技术无法达到厘米级定位精度；至于基于激光雷达的反向定位算法，则由于对多线束激光雷达的要求导致成本居高不下，无法大规模量产落地。研发低成本、高精度、高可靠性、可大规模量产的高精定位方案则显得日益紧迫。二、讨论如果您在融合定位方面有任何问题，写下您的问题，我们有专人来解答您的问题。现在，就请您将目光移动至右上角，发表您的第一个求助帖吧~ 

本次分享分为三部分：为什么需要多传感器融合？传感器融合的一些先决条件如何做传感器融合？为什么需要多传感器融合？首先，单一传感器在自动驾驶中，都有各自的挑战，所以先了解下常用的传感器的挑战是什么：1. Camera data照相机数据遇到的挑战：①  没有深度信息。② 视场角有限，以卡车的传感器配置来说，需要比较多的摄像头，这里用到了6个摄像头覆盖了270°的视场角。③ 摄像头受外界条件的影响也比较大，（上图右下方）这是当车行驶到桥下时，由于背光，且光线变化比较大，导致无法识别正前方的交通灯。2. Lidar data激光雷达数据的一个比较大的挑战是感知范围比较近，如右图所示，感知范围平均在 150m 左右，这取决于环境和障碍物的不同。激光雷达在角分辨度上远远不如照相机，如上图，有三条小狗在过马路，在照相机上可以清楚的看到，但是在激光雷达上，采集到的点是比较少的，这样的场景在每天复杂道路路测的时候会经常遇到。激光雷达对环境的敏感度也是比较大的，上图为 Pony 路测的时候经常遇到的虚拟噪点的 Case，在车经过建筑工地的时候，在图像上可以看到并没有任何的障碍物，但是在雷达上前面有很多的噪点，右边是雨天中的测试，车辆行驶中溅起来的水花，在激光雷达上都是有噪点的，如何去除这样的噪点，是我们经常面临的挑战。3. Radar data毫米波雷达，本身的一个挑战是没有高度信息，毫米波雷达能告诉你这个物体在哪个位置，但是不知道多高，这个 case 就是前面有一个比较高的指路牌，毫米波雷达知道这儿有个障碍物，但是不知道是悬空的。4. Why sensor fusion当看过了这些单一传感器在自动驾驶中面临的挑战，自然会想到，做多传感器融合，进行传感器之间的取长补短，来帮助整个感知系统效果的提升。这里的例子是，如何利用多传感器来提升感知的探测距离，当障碍物距离 150m 左右时，激光雷达的反射点已经比较少了，但是这时毫米波雷达和照相机还是比较稳定的。当障碍物驶出 200m 的范围，基本上没有任何的激光雷达反射点了，但是 200m 取决于自动驾驶车辆本身的车速是多少，200m 的感知距离还是必要的，这时只能通过毫米波雷达和摄像头，来提升对障碍物的感知距离，从图中可以看到障碍物还是可以稳定识别出来的。传感器融合的先决条件1. 运动补偿 & 时间同步① Ego motion为什么做运动补偿？在自动驾驶传感器感知过程中，传感器采集数据，一般都不是瞬时发生的，以激光雷达为例，采集一圈数据需要 0.1s，在这 0.1s 内，本身车会发生一定的位移，障碍物也会发生一定的位移，如果我们不考虑这样的位移的话，我们检测出来的位置就会不准确。位移有俩种，第一种就是车自身的位移 Ego motion。右边画了一个示意图，虚线部分可以认为是世界坐标系，红色的点代表一个静态的障碍物，它在坐标系中有一个稳定的坐标（5，5），蓝色部分代表车自己的坐标系是局部坐标系，（4，0）为这个坐标系的原点，在 t+1 时刻，这个坐标系移动到了（6，0）的位置，车沿着 X 方向向前移动了2，在 t 时刻在车自身的坐标系下，障碍物的坐标是（1，5），在 t+1 是时刻，则是（-1，5）。如果不做车自身运动的补偿，静止的物体在2帧之间，测量的局部坐标是不一样的，就会产生错误的速度，因此，要去补偿车本身的位移，做自身的 Motion compensation 运动补偿。这个问题比较简单，因为车是有比较准确的定位信息的，它会提供这俩个时刻，车本身的姿态差距，我们可以利用姿态差，比较容易的补偿车移动了多少，那我们就可以知道这个障碍物其实是没有移动的。② Motion from others第二种要考虑的是运动物体在传感器采集的时间段内，运动物体发生的位移，相对于自身运动补偿，这是一个更难的 case，首先快速移动的物体，在激光点云里很可能会被扫到俩次，大家可以看下红圈内，尾部会有拖影。所以我们如何想办法消除对方车的 Motion，也是要考虑的。解决的方式有很多，现在激光雷达本身从硬件上也会有些配置，来缓解这样的现象，简单解释下，当你用多个激光雷达在自动驾驶车辆时，可以让激光雷达按照同样的方式一起转，在某一个特定的时段，特定的方向，应该扫到同样的东西，这样来减少快速移动的物体产生拖影这样的问题。②   时间同步在很多自动驾驶车辆传感器中，大部分支持 GPS 时间戳的时间同步方法。这个方法比较简单，如果传感器硬件支持这些时间同步的方法，拿到传感器数据的时候，数据包中就会有全局的时间戳，这样的时间戳以 GPS 为基准，非常方便。但是，时间戳查询数据会有一个比较明显的问题，举个例子，图中有三个数据，三个传感器和时间轴，不同传感器是以不同频率来采集数据的，以传感器2为例，在 T1 时刻，传感器2有一个数据，在这个时刻，想知道对应的传感器1和传感器3的数据是多少，肯定需要去查找，查找的方式是找对应的传感器数据和传感器2时间差最近的数据包，然后拿过来用，这就取决于查的时候，数据包的时间和 T1 时刻传感器2数据包的时间到底差多少，如果差距比较大，本身障碍物都是在移动的，这样误差会比较大。然后就有了第二种时间同步的方法，来缓解刚刚说的这种现象。就是主动数据同步的方法，比如以激光雷达作为触发其它传感器的源头，当激光雷达转到某个角度时，触发那个角度的摄像头，这样就可以大大减少时间差的问题，如果把这套时间方案做到硬件中，做到比较低的误差，那么对齐的效果比较好。如上图所示，这时激光雷达的数据就很好的和摄像头的数据结合在了一起。刚才说到如果一个自动驾驶车辆用了多个激光雷达，激光雷达之间如何同步，减少扫到同样车在不同时间这样的问题，velodyne 是我们常用的一个品牌，支持一种 Phase Lock 功能，能够保证在某一时刻，所有的激光雷达的角度，都可以根据 Phase Lock 的配置，在固定的角度附近。这样如果用俩个前向的激光雷达都设置一个角度，在同一时刻，扫到的东西应该是类似的，这样一个快速行驶的车，被扫到2次的概率就会减少，当然这个办法也不能完全解决问题，比如有个人和我们的激光雷达以同样的频率一起转，那么在激光雷达扫描的点云中，人一直会出现，所以还要通过软件的方法，设置的一些规则或者模型来想办法剔除。2. 传感器标定接下来是另外一个比较大的话题：Sensor Calibration 传感器标定。这里主要是指传感器外参的标定。传感器外参其实就是刚体旋转，因为物体上的俩个点，在经过旋转和平移之后，两个点之间的 3D 位置是不会变的，所以叫刚体旋转，在自动驾驶和机器人上，刚体旋转还是比较常见的。传感器外参的标定就是要找到这样的一个刚体旋转，可以把一个传感器的数据和另一个对齐。相当于把一个传感器测量的数据从其本身的坐标系，通过刚体旋转，转到另一个传感器坐标系，这样就可以进行数据融合了。上图中，左边为图像，中间为雷达，如果有一个比较好的外参工具，可以把 3D 的点投射到 2D 图像上，所有的障碍物的点都可以对应上，相当于把 2D 上的像素都加上了深度的估计。这样在图像质量并不是很高的情况下，可以通过这样的方式把信息补回来。传感器的标定一般有俩种思路，第一种是有激光雷达的传感器标定，第二种是无激光雷达的传感器标定，之所以这么分，是因为激光雷达采集的数据是完整的 3D 信息，空间中的 ( x，y，z ) 都是准确的，并不会有信息的丢失，而照相机得到的数据，可以认为是极坐标系下的坐标，没有深度和角度，而毫米波雷达是没有高度的。所以，如果有这样的传感器能够提供完全的 ( x，y，z ) 坐标，以此为参照物，其他传感器和激光雷达做绑定的话，会更容易和更准确。Pony 是有激光雷达的，所以今天主要讲有激光雷达的传感器标定方法。①   Multi-Lidar Calibration首先讲下多激光雷达是如何标定的，上图可以看到正好用到的是两个前向激光雷达，这两个激光雷达在前向180°是有比较大的覆盖区域，如果对激光雷达之间的旋转和平移没有比较好的估计，当把俩张激光雷达的点云放在一起进行感知处理的时候，在红框位置会发现存在比较大的分隔（黄线和蓝线分别代表俩个前向激光雷达），这种情况肯定是不想遇到的，所以需要把多个激光雷达做比较准确的标定。标定的方法是已知的，非常好解决的问题，因为激光雷达本身是有完全的3D信息，解决这样俩个数据集匹配的问题，就是 ICP（Iterative Closest Point）迭代式最近点方法。这个方法有很多的变种，感兴趣的同学可以百度或者 Google 搜索下。②   Camera Lidar Calibration另外一个就是照相机和激光雷达之间的标定。照相机本身是没有距离信息的，那么如何去做标定？同样激光雷达是有 3D 信息的，可以通过标定的方式，把激光雷达投到图像的坐标系中，建立图像的像素点，和激光雷达投影后的点之间的匹配，然后通过某种优化方程，来解决这样一个匹配问题。举一个简单的例子，比如现在要选取一系列激光雷达检测出来的候选点，如何选这些点呢？这些点一定是在图像上比较容易能够识别出来的边界点。选取方法也比较简单，因为激光雷达有距离信息，只需要找相邻俩个激光点之间的距离差，就可以判断这样一个点是不是边界点，我们可以轻易的选出这样的候选点，通过这样的投影方式，红框是我们要求的标定参数，K 矩阵为相机本身的内参，通过这个数学关系，我们可以把刚才 3D 中检测的候选点，投到 2D 上，上图中的 X 就是投射后的位置。我们可以根据 3D 投影点和 2D 检测的边界，进行匹配，然后根据他们之间的距离匹配程度，建立这样一个优化方程，然后解这样一个优化问题，来估计出 Calibration 的参数。大家如果感兴趣可以参考这篇 paper：Automatic Online Calibration of Cameras and Lasers，详细的讲述了其中的数值原理，可以看到绿色的是 3D 点投射到图像上，是一些边界点候选的区域，如果有一个比较好的标定结果，这些边界点会比较好的和图像匹配起来。3. 传感器视场角接下来看下传感器不同视场角带来的融合问题。这里有一个简单的示意图，假设在这个位置上有两个激光雷达，它们有各自不同的视场角，但是前方有个障碍物 A 刚好在传感器2的视场角内把障碍物 B 完全遮挡了，障碍物 B 只出现在一个传感器检测的视场角内部，这带来的问题是：我们到底该不该相信这里存在一个障碍物？这是比较常见的问题，需要我们经过不断的路测，来完善。如何做传感器融合？1. Camera Lidar Fusion首先讲下照相机和激光雷达融合，方法1之前大概讲过，就是说激光雷达有 ( x，y，z ) 比较明确的 3D 观测，通过标定参数，通过照相机本身的内参，就可以把 3D 点投到图像上，图像上的某些像素就会打上深度信息，然后可以做基于图像的分割或者 Deep Learning Model。需要注意的是，多传感器的时候，视场角可能会不一样，可能会造成噪点或者漏点，这里比较推荐的方法是把照相机和雷达安装在一起，越近越好。另一个比较直观的方法，是否能将 2D 检测出来的障碍物直接投影到 3D，然后生成这样的 3D 障碍物，这种方法，在做很多的假设条件下（比如障碍物的大小，地面是否平整），也是可以做的，如上图，相机的内参，车的位置高度，都是已知的，这时在 2D 上识别出的每个帧的障碍物，都可以还原成 3D 在照相机坐标系下的一条射线，然后找这条射线在 3D 坐标系下和平面的交点，就可以估计出 2D 障碍物在 3D 上的距离。上图为 Pony 在建筑工地旁采集的数据，可看到这些路障都是直接生成到 3D 的（图中有个漏点，也是我们还需要努力提高的）。2. Radar Lidar Fusion至于毫米波雷达和激光雷达的融合方式就更简单了。因为在笛卡尔坐标系下，它们都有完整的 ( x，y ) 方向的信息，那么在普适的笛卡尔坐标系下，做针对于距离的融合，而且毫米波雷达还会测速，对障碍物速度也是有一定观测的，然后激光雷达通过位置的追踪，也会得到障碍物速度的估计，这些速度的信息也可以用来做融合，帮助筛选错误的匹配候选集。这是 Pony 激光雷达和毫米波雷达融合的效果，红圈里的障碍物是 radar 补充的。当然，不同传感器之间融合的特例还是很多的，比如激光雷达和毫米波雷达融合的时候，可以看到，这个场景是前方有比较高的路牌时，毫米波雷达会在这个位置产生障碍物，恰好激光雷达也有噪音，因为恰好前方有车，这时在牌子底下也会产生噪点，所以激光雷达和毫米波雷达都在这个地方检测出来本不应该出现的障碍物，这时两个传感器都告诉你前方有个障碍物，只有摄像头说前方只有一个障碍物，这时该怎么办？总结总结来说，每个传感器都有自己的一些问题，传感器融合就是说我们要把这些传感器结合起来做取长补短，提升整个感知系统的精度和召回度，今天就分享到这里，谢谢大家。文章转载自公众号DataFunTalk 

AI、5G生态圈的科技公司在做产品原型设计阶段采用最多的两种开发板有英伟达的Jetson和蓝莓派开发板，两种开发板的尺寸都比较小，并有成熟完善的生态圈，适合开发各种类型的终端设备。两种开发板各有特点和优势，英伟达Jetson平台基于超强的GPU算力，并提供开发工具，用于开发和部署 AI 助力的机器人、无人机、IVA 应用程序以及其他独立思考的自主机器。树莓派的尺寸相对于英伟达Jetson平台系列开发板要更小，更方便携带、功耗更低、价格更便宜，树莓派虽小，但五脏俱全和普通电脑无异，并同样具有强大的爱好者生态圈，可以实现智慧家庭终端、消费终端、AIoT等应用。随着5G网络的部署，各类5G终端产品在火热的开发中，这两类开发板的应用接入5G网络的诉求也越发强烈，目前的传统的方案是采用CPE或者手机等消费类终端，这类产品多为消费类终端产品并且软件开放程度不高，不利于二次开发，尤其是采用私有协议的垂直行业类终端。 针对这一痛点，本文介绍一种比较好解决方案：基于华为MH5000系列5G通讯模组做二次开发，利用其原生的5G网络接入能力可以非常方便的进行二次开发。华为MH5000系列模组的介绍在前序文章中有过介绍，这里就不重复描述了。基于MH5000系列模组，华为X Labs与合作伙伴一起做了一块尺寸较小的5G模组扩展板，用到了MH5000模组的电源、SIM、天线、USB等接口。一、硬件连接以树莓派为例，5G模组扩展模块的整体DIY方案及系统硬件连线图如下图所示。由于华为5G模组已经将基带、射频、存储、电源等芯片整体封装在一起，并对外提供了标准接口，所以整体的硬件连接方式比较简单，原理上就是将华为5G模组的USB接口引出接入到树莓派（或Jetson开发板）上，并供电。二、Linux内核驱动集成硬件连接部分主要是完成后，就是在开发板操作系统上完成驱动集成。两种开发板基本上都是基于Linux系统的，下面就以Linux系统为例子介绍一下集成的方法，主要涉及修改的Linux内核源代码文件为：linux_src/drivers/usb/serial/option.c linux_src/drivers/usb/serial/usb_wwan.c linux_src/include/linux/usb.h1、usb.h及option.c文件修改步骤 1 在 linux_src/include/linux/usb.h 中添加如下宏步骤 2 在 linux_src/drivers/usb/serial/option.c 文件中的 static const struct usb_device_id option_ids[]的 id 列表中增加如下语句,用于匹配设备数据（最新的usb驱动下实际只要更新最后一行即可，如下）。{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x06, 0x7D) },2、根据 USB 协议，添加关于传输中对于零包的处理。 修改文件为 ：linux_src/drivers/usb/serial/usb_wwan.c。步骤 1 增加对 bcdUSB 值的定义：#define HW_bcdUSB 0x0110；增加对华为 vid 值的定义：#define HUAWEI_VENDOR_ID 0x12d1。步骤 2 在linux_src/drivers/usb/serial/usb_wwan.c 文件中的usb_wwan_write函数内增加 定义：struct usb_host_endpoint *ep=NULL;步骤 3 在 usb_wwan_write 函数增加对零包的判断，增加位置如红框所示：3、内核文件的编译配置文本配置方式，修改 linux_src/目录下的.config 文件。1)         USB 串口驱动相关的配置项：CONFIG_USB_SERIAL=yCONFIG_USB_SERIAL_OPTION=yCONFIG_USB_SERIAL_WWAN=y2)         PPP 拨号的相关配置项：CONFIG_PPP=yCONFIG_PPP_MULTILINK=yCONFIG_PPP_FILTER=y CONFIG_PPP_ASYNC=y CONFIG_PPP_SYNC_TTY=y CONFIG_PPP_DEFLATE=y CONFIG_PPP_BSDCOMP=y4、编译和安装完成后，重启模组。1)         重启设备，模组上电，查询是否新增了wwan0、ttyUSB设备； 命令：dmesg2)         wwan0网卡自动获取IP： sudo dhclient wwan0详细的操作可以参考《华为模块 Linux内核驱动集成指导》 三、连接网络及测试以上完成后，开发板与5G模组直接已经连通了，可以执行拨号与速率测试了。1、  选用minicom等串口工具，登录模组，执行下面的AT命令进行拨号及调试。1)         拨号入网命令：at^ndisdup=1,1若加APN直接在后面添加”APN名称”如：AT^NDISDUP=1,1,"CloudVision"2)         查询IPAT命令：at+cgpaddr相关的执行结果可以参考如下：其他的一些模组及网络连通性测试命令，可以详细参考下面的文章，这里不做详细描述：链接：https://bbs.huaweicloud.com/forum/thread-42145-1-1.html2、  ifconfig检查系统当前的状态，可以看到拨号完成后，wwan0获取到了IP。3、  选用灌包测试工具测试网速（受限于测试网络及信号状态，实际网速仅做参考）上行测试结果：80Mbps下行测试结果：200Mbps 至此，树莓派或Jetson开发板已经完成了与模组的连接及调试，新增了5G网络连接的功能，可以正常连接到网络中作为一个5G终端原型进行实际业务开发了。后续将介绍一些基于“树莓派+5G扩展板”的5G行业终端原型及5G行业业务模拟器，欢迎大家持续关注。 大家对于5G模组及行业终端有兴趣的话可以参考以下的系列文章，有相关问题欢迎交流和咨询：华为X Labs实验室：yjw.yao@huawei.com第一篇：《5G 行业终端与模组系列 01 - 行业终端痛点与通讯模组》链接：https://bbs.huaweicloud.com/forum/thread-41869-1-1.html第二篇：《5G行业终端与模组02 - 行业终端环境可靠性设计》链接：https://bbs.huaweicloud.com/forum/thread-42044-1-1.html第三篇：《5G 行业终端与模组系列 03 - 5G行业终端（集成华为MH5000模组）网络连通性测试指导书》链接：https://bbs.huaweicloud.com/forum/thread-42145-1-1.html第四篇：《5G行业终端与模组04 - X Labs 5G行业终端应用集成验证服务》链接：https://bbs.huaweicloud.com/forum/thread-42182-1-1.html第五篇：《5G行业终端与模组05 - 功耗与散热设计》链接：https://bbs.huaweicloud.com/forum/thread-42421-1-1.html第6篇：《5G行业终端与模组06 – 天线设计》链接：https://bbs.huaweicloud.com/forum/thread-43905-1-1.html

5G行业终端与模组05 - 功耗与散热设计相对于4G终端设备，5G设备在基带模组功耗上要提升很多，典型的4G模组的功耗在3W，5G模组典型功耗在7W，翻倍了。功耗的增长不仅只是供电设计难度增大，还给散热、备电、噪声设计等增添了不小的难度。传统的4G模组热耗较小，很多场景下散热、供电不需要做专门的设计，但是5G则不然，需要专门考虑。很多小的终端公司没有专门的散热设计团队，也不具备散热仿真和测试优化的能力，面对5G模组的散热方案不知道怎么下手，华为X Labs根据华为无线产品散热开发经验以及和合作伙伴项目中总结如下几个散热设计建议：1、散热设计建议（1）MH5000模组需要增加散热器或贴外壳散热。如果空间受限，建议通过结构设计上贴壳散热。（2）模组与散热器之间需要有界面材料，推荐硅脂（导热系数≥3.3W/m2*K）3.3W/m2*K或凝胶（导热系数≥3W/m2*K），散热效果上，硅脂＞凝胶＞导热垫。使用界面材料的时候，需要在样机首轮结构组装时，打开散热器重点检视界面材料是否接触良好，接触面积至少占到芯片面积70%以上。（3）PCB 底部Bottom面大面铺铜，降热量分布开。增加PCB的含铜量可以减小电流损耗热阻和提升PCB的导热率，从源头和传播路径上上降低芯片温度。 2、温度传感器布局        温度传感器是在温控设计上最重要的组件，根据温度传感器的上报数值不仅可以了解当前终端的工作状态，也可以根据温度传感器调整整机的业务负载，保障整机的性能可以发挥到最优。温度传感器如何布局呢？是不是直接放在最热的地方就好？显然不是，具体建议如下：（1）布置在重点芯片周围，能够明显感知芯片温度变化。比如MH5000芯片、主CPU、电源、电池组等等，也可以考虑直接用芯片自身的传感器最为温控参考。（2）风冷方案在芯片下游位置。在使用风冷散热的时候，需要将板载的温度传感器布置在芯片的下游，以确保可以显著感知芯片温度的变化。（3）自然散热方案布置在芯片上方在使用自然散热方案的时候，热量都是向上方传递，需要将板载的温度传感器布置在芯片的上方。同时，自然散热方案的终端需要正确安装和使用，比如小的密闭空间或是侧卧时，需要考虑温度规格降额使用。 3、温控设计在散热设计上散热器、硬件设计是整体设计的“肉体”，而温控设计则是“灵魂”，直接关系到客户用的好不好。一个好的温控设计，建议做到如下的几点：（1）根据芯片或PCB温度逐渐调节风扇转速有些厂家为了减少设计难度，风扇不做调速处理，直接上电用，这样风扇会一直处于最大转速，一方面影响噪声和客户感受，另一方面也影响风扇的寿命。（2）高温时根据芯片温度适当业务降额好的温控设计会根据单板、芯片的温度来调整当前的业务负载，让设备整体的环境温度适应性更强，例如手机等PAD类终端产品的散热设计一般会布置许多个温度传感器，当设备主芯片温度过高时，会降低一些参数如屏幕亮度、分辨率等等，降低整体的热耗，保障设备可以可靠运行。（3）风扇的1+1备份，考虑寿命周期内免维护对于使用风扇的产品，需要考虑风扇的失效带来的影响，一般对于行业终端来说，风扇的成本微乎其微，可以考虑风扇1+1备份，整个生命周期内不用更换。    

没有小熊开发板，如何采集数据呀？教程上没有介绍，请解答一下。要不没法第一次作业打卡。

参加了7天IOT训练营，买了小熊派开发板，在iot后台配置后，小熊派开发板LED时亮时灭，好像没按照后台指令执行，这个怎么解决

1串口 摘要：主要讲解物联网的技术积累，首先从串口开始，本文基于GD32450i-EVAL对串口以及其通信做了一个简要的分析，以及开发过程中遇到的一些技术问题以及解决方案。1.1 定义  串口即串行端口，泛指采用所有采用串口通信时序的接口，一般在嵌入式中默认为UART口。1.2 串口的作用  （1）通过串口将程序下载到开发板  （2）显示调试日志实现对于运行程序的监控。  （3）通过串口发送或接收命令实现终端与开发板的信息交互。2 串口通信2.1 定义  在串口中，数据按顺序一位一位的传输，该传输方式成为串口通信。2.2 串口通信的传输方向  （1）单工：数据只可以沿一个方向传输。  （2）半双工：数据可以分时的沿着两个方向传输，即不能同时进行。  （3）全双工：数据可以同时进行双向传输。2.3 波特率  波特率指的是每秒传输多少位数据，即传输率。常用波特率为9600和115200.2.4 数据包  数据包 = 起始位 + 数据位 + 校验位 + 结束位3 GD32F450i的串口  对于GD32F450i开发板主要通信接口包含4个USART（USART0/1/2/5）和4个UART（UART3/4/6/7）。以USART0为例，具体原理图如图1所示。图1 串口原理图  由上图可知，引脚PA9和PA10位串口USART0的数据输入（接收）引脚RX和数据输出引脚TX。4 串口初始化的步骤（1）    使能GPIO的时钟。（2）    使能UART0的时钟。（3）    设置USART TX的引脚或端口。（4）    设置USART RX的引脚或端口。（5）    设置USART TX对应引脚为推挽输出工作模式。（6）    设置USART RX对应引脚为推挽输出工作模式。（7）    设置波特率为115200。（8）    使能Rx、Tx端口。4.1 串口模式  （1）普通模式：在主函数中接收函数，输出字符串到串口。     1）开发环境     Windows、Keil、Jlink下载器、GD32F450i-EVAL（2019）  注意：若使用的MDK版本为Keil5.25以后，打开项目时以及使用J-Link下载器烧录程序时可能会报错，针对可能出现的问题进行分析以及解决，链接为https://bbs.huaweicloud.com/blogs/123604。     2）程序重点  为实现通过printf函数打印字符串和输出实时数据到串口助手，需要重写fputc函数，同时添加头文件 #include "stdio.h"，重写函数如下所示。      int fputc(int ch, FILE *f)     {            usart_data_transmit(EVAL_COM1, (uint8_t)ch);            while(RESET == usart_flag_get(EVAL_COM1, USART_FLAG_TBE));            return ch;       }   3）硬件连接 连接USB供电线后，将J-Link下载器连接到开发板的JTAG接口上，之后连接到PC端，若LED5点亮说明选择了正确的启动方式，供电正常。硬件连接图如图2所示。供电方式选择GD-Link，串口采用九孔com口串口线（本文中使用杜邦线代替）连接。图2 硬件连接图之后点击keil5的编译和烧录按钮，如图3所示。图3 编译与烧录上述过程实现了下载程序到开发板，用跳线帽将JP5跳到USART0上，并将串口线连接到开发板的COM0上，例程首先将输出“USART printf example: please press theTamper key”到超级终端。按下 Tamper 键，串口继续输出“USART printf example”。通过串口输出的信息如图4所示。图4 串口输出（一）（2）中断模式：产生的不影响主程序运行。主函数中需要使能接收中断和发送中断即分别将对RBNE和TBE状态寄存器进行操作，触发中断。测试时首先，所有的LED灯亮灭一次。然后EVAL_COM0将首先输出数组 tx_buffer 的内容（从 0x00 到 0xFF）到支持 hex 格式的串口助手并等待接收由串口助手发送的 BUFFER_SIZE 个字节的数据。MCU 将接收到的串口助手发来的数据存放在数组 rx_buffer 中。在发送和接收完成后，将比较 tx_buffer 和rx_buffer 的值，如果结果相同，LED1，LED2，LED3 轮流闪烁；如果结果不相同，LED1，LED2，LED3 一起闪烁。通过串口输出的信息如图5所示。图5 串口输出图（二）（3）DMA模式：与主函数互不影响，独立运行。主函数中需要先使能USART0的发送和接收DMA通道，触发DMA。对于测试，DMA测试过程与中断方式相同。通过串口输出的信息如6所示。图6 串口输出（三）        通过以上的开发流程，对于物联网中的串口有了更深的认识。主文博客链接：https://bbs.huaweicloud.com/blogs/124244

LITE OS下载程序到开发板，能否设置一个密码，限制无关人员无法下载程序到开发板？虽然没有看到上传程序的按钮或菜单，肯定是有方式读取开发板里面的代码，这也是个安全性的问题。

从51单片机的keil工程不会建到现在狠心勒紧裤腰带买小熊派，这其中到底发生了什么？是人性的扭曲，还是道德的沦丧？现在为大家揭晓STC89C51，没错，就是大学的内容，我是参加Ti杯电赛才接触到的这个东西，由于没有上过这种课程，keil工程都不会建，所以之前去当了锡的搬运工——硬件电路，模电了解一下后来直接焊接有了一定的刷子，就直接上贴片，SMT，本来电路就让人头大，运放，差动，差模，高通有源滤波分分钟让人歇菜，然而虽然很难，但也抵挡不了电子的诱惑，谁让这些小小的电阻电容和IC芯这么可爱呢，不把他们一个个焊接到焊盘上去，怎能忍心让他们孤零零的待在外面呢？然后，现在我又看到了小熊派物联网开发板子，乍一听，蛮萌的秘密名字，就开搞吧。然后就开始了，远程点灯之旅，然后就到了现在。未来不知道会怎么样，但是找到光的方向，一直走下去是一定没有错的。

BC95开发板与OceanConnect使用coap通信，上行数据是没有问题的，但下行时数据延迟6次，也就是我下发当前数据，但BC95开发板收到的是6次之前的数据。以此类推，数据总是延迟6次，请问这是什么原因？？？谢谢！！