没啥用的小知识！

C++怎么在main之前print一个东西

在论坛上看到一个很搞的问题,正常程序执行都是从main函数开始，要在这之前执行print，哈哈哈。。。。只能想到构造器。

1
2
3
4
5
6
7
8
9
10
11
12

class TT {
public:
    TT() {
        std::cout << "print_a_line" << std::endl;
    }
};

TT t1;
int main(){
    std::cout<<"whats_up_man"<<std::endl;
    return 0;
}

智能座舱

##白皮书

最近在阅读关于智能座舱的行业现状，看到这个，遂发出来共享给大家。
个人看来，座舱域更需要关注的信息不是娱乐以及覆盖手机的功能，更应该提供给用户行车更好的体验
例如HUD的布局，传统仪表盘会慢慢淘汰这是事实，做性能车的就搞”科技感加持性能“，做家用车就搞”舒适和实用“。
此外，座舱域也可以集成一些实用的功能，舱泊一体是个好方案，将AVM、AVP、APA功能集成进座舱域以后一定有市场。娱乐功能没那么重要，真开车肯定要认认真真开的！！！下班停到地库抽支烟的功夫，也是抱着手机的居多。
PS：移动端如果看不到这个PDF的话，只能换电脑来看了，QAQ。
这个白皮书写得很不错，值得一看。
白皮书

鱼眼相机环视系统

此段笔记记录在对鱼眼广角相机标定、拼接的过程中遇到的问题和解决思路，并辅以相关的基础知识备忘。
源代码可以下载如下两个压缩包,1用锁实现了同步、2只是简单拼接。两者方法思路基本都是一致的，都可以作为了解原理的起点：
点击下载代码 1
点击下载代码 2
标定板的制作参考如下：
Camera Calibration Pattern Generator – calib.io
https://calib.io/pages/camera-calibration-pattern-generator
可以使用这个小软件来制作标定板

概念整理

先理清两个概念：
1、畸变系数

畸变系数，畸变主要分为径向畸变和切向畸变。
①径向畸变，沿着透镜半径方向分布的畸变；
产生原因：是由透镜质量引起的，光线在远离透镜中心的地方比靠近中心的地方更加弯曲。径向畸变主要包括桶形畸变和枕形畸变两种。
就好比把一个直线拉弯了，哈哈镜都玩过，一个原理
产生的原因是透镜形状和质量引起的，一般来说市场上的鱼眼相机是桶形畸变
②切向畸变，
切向畸变是由于透镜本身与相机传感器平面（像平面）或图像平面不平行而产生的。 切向畸变主要发生在相机传感器和镜头不平行的情况下；因为有夹角，所以光透过镜头传到图像传感器上时，成像位置发生了变化。

[k1, k2, p1, p2, k3]
如果是使用的opencv的接口做的标定的话，那么畸变向量的顺序是这个样子的
其中k指的是径向畸变radial distortion
p指的是切向畸变TangentialDistortion

该脚本用于对局部特征子图进行处理

参考广汽研究院发表的论文复现了其对应的算法并做了改进，由于在停车位识别方面，传统图像处理的算法效果并不好，真的要使用，还是要采用带有深度学习的方案

背景技术

这一章由于其特殊性和数学推导的复杂，很难写得很细。我在此只叙述实现的一些方法和一些意见。具体的工程，在附件中有多份深度学习的源码，可以研究和使用。
传统的方案是采取直线检测来做的，在AVM图像里，用二值化之后利用霍夫变换来对直线进行检测，可能还会用到聚类算法等，最后来拟合构成车位。
但是这一大类利用传统图像处理的方法准确率都偏低，很容易漏检或者混检。

利用深度学习的方法，缺点是必须要使用带算力的SoC，价格一定是相对昂贵的，不管是GPU还是NPU，严重依赖硬件加速，即使对模型进行量化压缩，想要高效又准确也是个难题。
并且各家都在主推自己的工具链，想要在激烈的市场竞争中分得最大的这一块蛋糕，地平线有天工开物，黑芝麻有华山，TI有TIDL，英伟达有TensorRT和CUDA等等。

深度学习的效果，经过实际的验证，确实比传统图像算法优秀得多，以往的方法都是使用人手工精心设计的特征，来进行提取和处理，
比如说利用频谱特征、小波变换、SIFT、ORB、HOG等，但不是所有问题都可以用深度学习来解决！
深度学习本质上强大在非线性拟合能力，用一个三层的神经网络能拟合出任意的函数，但具体问题具体分析，它并没有那么“智能”。

目前已有的空闲车位识别技术可以分为基于超声波雷达探测，基于视觉的空闲车位识别以及超声波与视觉相融合3 种基本模式。
得益于360°环视成像技术的成熟发展，基于环视图像的全视觉空闲车位线识别方法较为成熟了。
在其他学者既已提出的众多研究车位线自动识别方法中，可划分为依据线检测与依据角点检测定位车位两种基本思路。

C/C++ Advanced Lint

1

一个 Visual Studio Code 扩展，支持许多用于 C 和 C++ 代码的静态代码分析器。

在文件保存时或文件编辑后，代码编辑器中的即时 linting。
自动查找可用的静态分析工具。
以最少的开发工作量轻松支持其他静态分析器。

1
2
3
4
5
6
7

Supported Static Analyzers
Clang
CppCheck
FlawFinder
PC-lint Plus
Flexelint or PC-lint
lizard

要求您的机器上必须至少安装上述静态代码分析器之一。
扩展应该支持列出的静态代码分析器的任何版本；并将尝试在您的 PATH 环境变量中找到它们。
如果未自动找到工具，则必须手动指定适当的 c-cpp-flylint.*.executable 配置。

1
2

Debian & Ubuntu Clang 可通过 apt-get 获得：# sudo apt-get install clang 
CppCheck 可通过 apt-get 获得：# sudo apt-get install cppcheck

DMPR论文：DMPR-PS A NOVEL APPROACH FOR PARKINGSLOT DETECTION

这篇论文的思路很巧妙，是同济大学在2019年做的一些工作，数据集使用的是ps2.0
我写的一些初步解析可以下载：解析
论文原文下载：原文
其实现在车位识别还是分成三个大方向
一是传统的超声波检测，这种方法使用的工况还是有局限性的，必须要在前后有障碍物的时候才行
二是采用视觉检测，这种方法也存在许多局限，比如说车位线不清晰的情况，还有没有车位线的情况。
视觉这里面还有很多种思路，比如说采用语义分割来对地面进行识别，还有比如说采用目标检测的方法，不管是YOLO还是RCNN系列或者SSD，检测车位入口的角点来构成车位。

自动驾驶的三个板块

感知模块

感知模块：负责三类任务，运动状态估计、自身位置估计、外部环境态势观测。
从传感器采集信号开始，感知模块就已经在运作了，这个模块复杂程度最高，技术难度最大，各种不同的传感器采集的信号不同，组织形式不同，所以难度也很大。例如：核心的几个东西，
IMU：即惯性测量单元，确定当前速度、加速度、横摆角速度、前轮转角状态
定位：北斗、GPS，提供经纬度坐标值，RAC技术
视觉传感器：车身一般会配备多个摄像头，包括多个大角度鱼眼摄像头、前后向的远视距摄像头等。
激光雷达：提供车身周围一定范围的点云信号，可以理解为距离
毫米波雷达：如果要测得远，可测量的角度就会变小。毫米波雷达分为24Ghz和77Ghz频段。测距测速能力强。在雨雪天气时的鲁棒性很好，但是对高处物体和小物体检测效果有限。
超声波雷达：测量的距离更近了，因为频率更低，低频波束在传播中容易耗散
好，有这几个东西，基本上感知系统就有一些保障了
当然，单个传感器的原始数据很多很复杂，每一个的置信度都不是百分之百，所以要有组织形式，这个也属于感知模块要做的事情
例如，视觉传感器要和雷达传感器相互配合，锁定值得关注的目标，辨识目标的类别，追踪并预测其未来运动的趋势。此外还有V2X这样的方法来弥补不足。

YOLO_V数据集制作方法及如何更换其backbone

写在最前面：
出于兴趣，我针对轻量化神经网络的训练和部署做了一些相关的研究，在此做一个学习过程记录
首先是数据集的制作，在以下网址可以找到我分享的关于AVM的一个数据集，label：
‘’‘’‘’‘（待上传）
第一步是从一堆相似性太高的数据集里面筛选出一些合适的样本，并移动至目标目录，更改好名字
参考以下的脚本

第一章：数学概念

1、图像矩的概念：
本质上来讲图像的矩是统计学上的概念，它是通过描述统计学特征来对图像内容进行描述的一类描述子。

第二章：代码实现

1、如果你使用OpenCV这个库的话，那么可以直接使用现成的API来使用它：CV::moments
这个方法将返回一系列的矩。如果是使用python，注意返回的数据是字典，要用get（“mxx”）来读取某一个元素。
并且，注意输入给函数的源图要是二值图像。
python参考以下的代码：
more >>

驱动是什么东西？为什么需要驱动？

从计算机的眼睛里看，设备就是一组寄存器，比如说IO设备， 串口，键盘，磁盘，打印机，总线，中断控制器，DMA，GPU 这些设备就是挂在计算机下面的。那么，操作系统，如何使应用程序能访问这些设备？

本质上需要驱动的原因：操作系统需要能够访问和操作这些设备。

我们知道，IO设备在计算机看来，或者说在处理器看来就是一组#寄存器和协议#。

本节内容主要解决两个问题：

1、什么是设备的驱动程序

2、Linux设备抽象

设备驱动程序原理

IO设备的主要功能：输入和输出能够读写字节序列，流或者数组常见的设备都满足这个模型

终端/串口–字节流char_device 打印机–字节流，例如postscript文件 硬盘–字节数组，按照块访问 GPU–字节流（控制）+字节数组（显示存储器）

1
2
3
4
5

所以：
操作系统：设备 == 支持各类操作的对象（文件）
read --从设备某个指定的位置读出数据
write --向设备某个指定位置写入数据
ioctl -- 读取/设置设备的状态

把设备的寄存器直接暴露给用户是很糟糕和危险的，这显而易见。 这样，也给应用层的软件带来了很大的负担，出错的代价也会很大的 所以，我们要对设备做抽象，要在操作系统和实体设备（寄存器和协议）之间做一个抽象的层
这个尽可能统一的方式，如同一层API，就是设备驱动程序 我们不用知道寄存器的编号是多少，不用知道写进去后怎么样才能操作完成 这一层，就叫做驱动。

所有的这些设备：I/O设备，最重要的功能就是：数据往应用里送往外出。 char——device

补充一下字节流byte_stream，比如说，键盘的按键，它输入的就是一系列的事件，按下的这一大串按键 就可以看作一个字节流

block——device一块一块的，字节块。 有意思的事情：我们的显卡，是什么设备？ 显存不是按块访问的，显卡暨是字节流，又是一个字节数组
驱动

这一大坨设备的抽象，最重要的就是读写和控制，设备驱动程序就是为设备建立起这个模型的代码
需要一段代码，需要把例如read这一段系统调用，翻译成设备寄存器能听得懂的这一段话。
这一段代码，把系统调用翻译，注意是翻译，我们能看到的一大坨通用API,变成一堆五花八门的设备之间的翻译

其实shell也是类似的原理，
shell是把命令，翻译成一组系统调用，这些系统调用的序列，再通过驱动层，翻译成为了实际的寄存器操作，被执行了起来，就是一层层往下的这个过程