Add a post.
This commit is contained in:
parent
7fed533acf
commit
c8b3324407
78
source/_posts/NaoVision-General-Introduction.md
Normal file
78
source/_posts/NaoVision-General-Introduction.md
Normal file
@ -0,0 +1,78 @@
|
|||||||
|
---
|
||||||
|
title: NaoVision
|
||||||
|
date: 2019-10-09 23:22:44
|
||||||
|
tags:
|
||||||
|
---
|
||||||
|
|
||||||
|
# NAOVision 帮助文档
|
||||||
|
|
||||||
|
## 项目概要
|
||||||
|
|
||||||
|
### 简介
|
||||||
|
|
||||||
|
NaoVision是实物NAO组的有关于NAO机器人在RoboCup比赛中的专用视觉方法解决方案。NaoVision使用C++编写,旨在解决NAO机器人在Bhuman系统在原始的固定阈值方案下对于场地的颜色判别容易由光线等因素干扰,导致在实际的比赛过程NAO机器人中对于场地内的物体(特别是足球)的识别不够快速、准确的问题。
|
||||||
|
|
||||||
|
在对于足球场地的判断上,相对应的,NaoVision采取OTSU算法,实现对于图像处理阈值的自动调整,能够不受光线阴影的影响,在大多数情况下正确地识别并标记出场地像素。
|
||||||
|
|
||||||
|
在场地颜色判别的基础上,NaoVision通过在图片中建立扫描线。通过对扫描线所在的像素进行采样与扫描,确定场地与非场地的分界点。而后通过在分界点之间进行连线,将图片划分为场地部分与非场地部分。
|
||||||
|
|
||||||
|
一般而言,为了降低计算开销,NaoVision只对于属于场地部分的图片像素进行计算。在确定计算范围之后,NaoVison将在计算范围内建立间隔更小的扫描线,针对计算范围内部的物体进行更加细致的扫描与探测。
|
||||||
|
|
||||||
|
而后,NaoVision有限对于场地内的圆形物体进行探测。程序将在扫描线上进行均匀的跳跃扫描,在探测到计算范围内不属于场地的像素后,在该像素周围随机选取三个不共线的点。以这三个点为基点,分别朝向八个方向进行扫描,知道探测到场地像素后返回。而后判断这24个有效点是否在一个圆上,并同时计算出圆的圆心坐标及其半径。将该圆加入候选队列后程序将继续对计算区域剩下的部分进行扫描。
|
||||||
|
|
||||||
|
(未完待续)
|
||||||
|
|
||||||
|
### 主要组成部分
|
||||||
|
|
||||||
|
在NaoVision的解决方案下(采用 Visual Studio 2019开发),有
|
||||||
|
|
||||||
|
- **NAOFastTools** 核心工具组工程
|
||||||
|
- **NFTCommandLineTools** 通用命令行工具
|
||||||
|
- **NFTDeamon** 守护进程
|
||||||
|
- **NFTGUI** 调试界面工程
|
||||||
|
- **NFTTest** Opencv对接工具组工程
|
||||||
|
- **UnitTest** 单元测试工程
|
||||||
|
|
||||||
|
### 简要流程简介
|
||||||
|
|
||||||
|
问题说明:由于将NFT与BHuman的直接嵌入方案遇到了种种问题,本项目拟采用独立进程伴随BHuman的方式。
|
||||||
|
|
||||||
|
在实际的比赛过程中**NAOFastTools框架**被**NFTDeamon守护进程**驱动,与Naoqi、BHuman并行运行在NAO机器人的系统中。**NFTDeamon守护进程**通过共享内存的方式与BHuman通信,从BHuman获取摄像头数据,经过计算后,向BHuman传递视觉的修正信息。在平时的调试过程中,可以使用**NFTCommandLineTools通用命令行工具**或者**NFTGUI调试界面**与**NFTDeamon守护进程**建立连接来监视与调整**NAOFastTools框架**或者**BHuman**的运行状态与相关参数。
|
||||||
|
|
||||||
|
(未完待续)
|
||||||
|
|
||||||
|
#### 组成部分简介
|
||||||
|
|
||||||
|
##### 1. NAOFastTools核心工具组工程
|
||||||
|
|
||||||
|
NAOFastTools核心工具组(以下简称NFT)中存放着该解决方案的进行图像处理与储存的核心框架以及对应的图形处理模块,是该解决方案的核心工程。该工程遵循C++14标准,少部分代码含有C++14的特性(安装有BHuman2018的系统含有支持C++14的libstdc++.so)。NFT最终生成在Windows与Linux下是对应的静态链接库(NAOFastTools.lib与NAOFastTools.a)。NFT通过与其他程序链接来发挥作用。除了在VS环境下进行编译,NFT框架还可以在Linux环境下进行编译,前提是正确安装clang、make、cmake工具。下面是NFT中几个特别重要的常用类与函数(包括不限于下列)的极其简单的介绍(实际使用需要看代码理解)。
|
||||||
|
|
||||||
|
OperaMatrix是代理类,是对于Eigen线性代数库的Matrix类的一层代理访问。除了提供代理访问服务之外,它还提供智能指针服务,能够根据引用计数自动创建与释放Matrix对象。一个或者多个OperaMatrix对应一个Matrix对象。OperaMatrix对象提供多种构造函数,满足用户在大多数情况下的需要。OperaMatrix中的元素在内存中按照列优先的方式储存,用户可以通过getData()接口直接获得指向矩阵首元素的指针。OperaMatrix对应的矩阵的行数与列数能够使用getRows()与getCols()获取。
|
||||||
|
|
||||||
|
Image类是图像的储存载体,它含有一个或者多个OpreaMatrix对象,对应图像的多个通道。一个OperaMatrix储存相应的一个通道的像素数据。正常情况下,像素数据的类型(PIXEL_TYPE)定义在NFT.h中。图像的通道数量能够使用getColumns()方法获取,某个通道的引用可以直接使用[]运算符获得。图像的高与宽则使用getHeight()与getWidth()方法获取。
|
||||||
|
|
||||||
|
ImageYUV422类继承自Image类,它提供压缩颜色空间YUV422的储存。需要注明,它有且只有一个通道。在具体的内存实现上,它将三个通道的像素数据压缩到一个通道进行储存。如果需要获取某个像素的Y、Cr、Cb值,则可以调用getY(int, int)、getCr(int ,int)、getCb(int, int)进行访问。进一步,如果需要修改图片中的某个像素的Y、Cr、Cb值,则调用相应的setter并提供像素的坐标参数即可。
|
||||||
|
|
||||||
|
ImageColored类继承自ImageYUV422类,也有且只有一个通道。它主要提供单通道图像的储存功能,是场地颜色判别模块的输出结果的储存载体。它也是其他很多视觉模块的输入数据的储存载体。它禁用了ImageYUV422父类的所有的有关于YUV颜色空间的操作的特性。
|
||||||
|
|
||||||
|
ImageSaver类是Image类的储存服务类,能够将Image对象中的数据正确储存在Windows或者Linux系统中的文件中(.nftd后缀)。它也能够通过读取.nftd格式的文件来构建相应的Image对象。
|
||||||
|
|
||||||
|
(未完待续)
|
||||||
|
|
||||||
|
##### 2. NFTGUI调试界面工程
|
||||||
|
|
||||||
|
NFTGUI调试界面基于Qt5,是有关于NAOFastTools的可视化调试界面,能输出进行各个图形处理模块的处理的中间结果及内部相关参数。
|
||||||
|
|
||||||
|
(未完待续)
|
||||||
|
|
||||||
|
##### 3.NFTTest Opencv对接工具组工程
|
||||||
|
|
||||||
|
NFTTest Opencv对接工具组是NaoVision框架与OpenCV框架对接的桥梁,它提供了两个框架之间的主要数据结构之间的转换函数,此外,该工程也用于开发过程中的最基础的调试信息输出。
|
||||||
|
|
||||||
|
(未完待续)
|
||||||
|
|
||||||
|
##### 4.UnitTest单元测试工具
|
||||||
|
|
||||||
|
基于Google Test测试框架,存放NAOFastTools中的核心框架的单元测试代码,这些代码将保证核心框架能够高效、准确地运行,也方便及时发现框架中的漏洞。
|
||||||
|
|
||||||
|
(未完待续)
|
Loading…
Reference in New Issue
Block a user