MOOS程序解析记录（4）

系列文章目录

---

本文内容主要整理自中国海洋大学硕士论文《基于MOOS的自主式水下机器人软件系统的设计与实现》作者侯健钊，其AUV系统对我有很大学习指导意义，于是我对自己所需要的部分进行了一定的梳理和整理。

---

前言

---

一、MOOSDB消息分发机制？

1.客户端A先通过调用CMOOSClient类中的Notify()函数将消息Msg存储在OutBox中。
2.然后通过信息传递线程Common thread调用Call in（）函数想MOOSDB发起链接请求
3.MOOSDB会在空闲状态下回复请求
4.在M00SDB接受连接请求的同时，将OutBox中的Msg数据打包成完整的数据包传输到MOOSDB中，MOOSDB对信息进行注册和分解，然后对客户端程序进行信息需求分析。
5.客户端Client A的请求分析将处理后的数据发送到InBox中，之后客户端程序调用接口函数Fetch()来获取所需要的信息，并根据不同任务执行后续的工作。

二、通信机制分析

MOOS系统与APP之间的通信整体上呈现一对多的星型分布，好处是便于二次维护与开发，添加减少模块可以直接进行。缺点是当信息发生堵塞时，整个系统可能会陷入瘫痪状态，不过由于AUV搭载的模块数量较少，所以一般不会遇到相应的问题。
AUV整体的MOOS系统框架如下：

1.串口通信模块的设计

linux下调用串口函数，AUV设计采用RS232串口来进行通讯，串口通信函数如下：
1.打开串口

fd=open(”／dev／ttyS0”，O—RDWR 0—NOCTFY)；

在Linux操作系统中，硬件设备接口被定义在设备管理器文件dev中，dev／ttySO表示串口1，也就是COM1，串口在打开时可以设置三种状态：O_ RDONLY只读打开、O_WRONLY只写打开、O_RDWR读写打开。标示符fd表示COM接口设备描述符，后期操作都是通过控制fd来完成对硬件设备的实际操作。
2.配置串口
主要是配置COM通信属性，包括串口波特率、奇偶校验位、数据位、停止位的设置。在Linux系统中通过配置mrmms结构体来实现对串口属性的设置，该结构体定义如下：

slruct termios
{
tcflag_t c_input__flag；
tcfiag_t e_output_flag；
tcflag_t ccontrol_flag；
cc——t c_line； ／／line discipline
cc—t c_CCONICC； ／／control characters
)

3.读写串口

read_Byte=read(fd，buffer-Size，len舀h)；
write Byte=write(fd，buffer-Size，length)；

其中fd是打开串口的设备标识符，buffer-Size是串口读写数据存储缓冲区的大小，length是读写串口一次的字节长度。
4.关闭串口
close(fd)；//串口作为文件来处理
MOOS与串口平台通信模型如下图所示：

2.以太网模块的设计

以太网具有传输量大、传输速度快的特点，一般用来对数据量大的传感器数据进行传递。以太网模块主要是包括PC和外部以太网口的通信以及PC和MOOSDB之间的通信。MOOS中的网络通信模型是TCP／IP协议的扩展应用，主要是基于Socket套接字而实现的。

其中服务器中的执行模块是基于Sebct网络通信模型而实现的。Sebct网络通信模型是Socket套接字中搭建服务器端程序常用的模型，该模型基于TCP协议，构建的服务器模型具有单线程并发循环的特点，其最大的优势就是可以在单个线程中同时管理多个套接字，并且可以建立多个网络连接，从而大大提高了网络通信的效率。
MOOS以太网通信模块中，实现快速以太网通信的设计过程如下：外设传感器通过以太网口与PCI04进行硬件连接，然后PCI04采集传感器的信息并进行存储，之后PCI04通过基于TCP／IP协议的Custom-Server模型，与MOOS平台传递服务器MOOSDB进行通信。

2.CAN总线通信

CAN是控制器局域网络(ControllerAreaNetwork，CAN)的简称，是国际标准化的串行通信协议的简称。CAN信息的发送一般采用查询方式，接收常采用终端方式。

CAN总线会将传感器上的硬件状态使用协议标准统一进行封装，一次性以完整的数据协议包发送给协议转换板。

CAN数据包通过协议转换板将数据进行封装，并打包发送给串口写线程，并通过串口接口和PC进行通信，PC通过Socket网络通信和MOOSDB实现信息传输功能。在整个模型中，MOOSDB把舱内传感器信息和电机状态检测作为一个独立的APP进行点对点的通信和数据管理。

三、舱外通信机制分析

AUV在水中执行使命的过程中，需要岸基控制系统对AUV进行有效的跟踪和检测，并将其实时显示在人机交互界面上，当AUV在水下时，多采用超短基线来进行AUV的通信和定位，当AUV在水面时，在短距离内采用无线电台来确定AUV的位置，远距离时采用铱星接受系统来确定AUV的位置。

1.铱星通信模块设计

使用铱星通信模块，可以直接通过RSS232串口就实现AUV的数据通信和定位功能。无需使用者了解铱星的内部通信机制，直接使用接口即可。

通常会在AUV舱内安装一个模块，在舱外再安装一个模块，舱内是AUV的系统发射端，舱外是AUV的系统接收端。

通信过程如图所示，首先MOOSDB实时检测AUV的各项状态，在经过处理后发送给铱星通信的协议转换板，由通信协议转换板打包数据，通过AUV的铱星发射模块发送给岸基控制系统，岸基控制系统通过铱星接受端进行接受，再通过协议转换板转换数据包后，经串口发送给岸基控制系统和母船作业系统。

2.无线通信模块设计

无线电通信和铱星通信系统实现过程基本一致，无线电通信系统采用两个无线电台来进行消息的手法，最后通过通信协议转换板来解析数据包，来实现水下机器人和岸基系统之间的通信交流。

3.水声通信模块设计

通过使用超短极限USBL设备，可以实现AUV和母船之间的通信，SUBL可以实时把水下机器人的位置和姿态信息发送给母船，同时可以接受母船发送的指令。也是通过AUV上的MOOSDB将所需要的信息数据通过水声通信APP进行读取并进行发送给，母船通过USBL的接收端进行接受，一般是通过串口发送到PC上。

四、AUV数据采集系统

由于不同传感器的数据量不同，对于数据量较大的传感器比如水下摄像头以及声纳会将其使用以太网络进行通信，而数据量相对较小的传感器比如惯性姿态导航系统（AHRS）、DVL等传感器则使用串口通信，而舱内其他信息和推进器的相关信息则通过CAN总线统一打包到串口进行通信。而两个PC之间通过IP的设置可以使用pShare模块进行通信。

总结

进程和线程

进程是资源分配的最小单位，线程是CPU调度的最小单位。
做个简单的比喻：进程=火车，线程=车厢
线程在进程下行进（单纯的车厢无法运行）
一个进程可以包含多个线程（一辆火车可以有多个车厢）
不同进程间数据很难共享（一辆火车上的乘客很难换到另外一辆火车，比如站点换乘）
同一进程下不同线程间数据很易共享（A车厢换到B车厢很容易）
进程要比线程消耗更多的计算机资源（采用多列火车相比多个车厢更耗资源）
进程间不会相互影响，一个线程挂掉将导致整个进程挂掉（一列火车不会影响到另外一列火车，但是如果一列火车上中间的一节车厢着火了，将影响到所有车厢）
进程可以拓展到多机，进程最多适合多核（不同火车可以开在多个轨道上，同一火车的车厢不能在行进的不同的轨道上）
进程使用的内存地址可以上锁，即一个线程使用某些共享内存时，其他线程必须等它结束，才能使用这一块内存。（比如火车上的洗手间）－“互斥锁”
进程使用的内存地址可以限定使用量（比如火车上的餐厅，最多只允许多少人进入，如果满了需要在门口等，等有人出来了才能进去）－“信号量
进程和线程部分转自知乎
链接：https://www.zhihu.com/question/25532384/answer/411179772