12.2-机器人协作系统

本文使用COMET方法对机器人协作系统进行软件建模与设计，并使用LabVIEW Actor Framework 进行详细设计。

关于这篇文档为什么要做这些，以及具体是如何做的，请参考文献[1]

参考文献

[1] Gomaa H. Software Modeling and Design Software Modeling and Design: UML, Use Cases, Patterns, and Software Architectures[M]. Cambridge University Press, 2011.

[2] Kim M, Kim S, Choi M, et al. UML-based service robot software development: a case study[J]. International Conference on Software Engineering. 2006: 534-543.

[3] Gamma E, Helm R, Johnson R. Design Patterns: Elements of Reusable Object-Oriented Software[M]. 1994.

[4] Mklab. StarUML Documentation[M]. Release 2.0.0 ed. 2015.

[5] Aristosqueue. READ THIS FIRST to get started with Actor Framework[Z]. NI Community, 2011: 2015.

[6] Lippman S B, Lajoie J, Moo B E. C++ Primer[M]. 5 ed. Pearson Education Inc., 2013.

[7] 邵维忠，杨芙清. 面向对象的系统分析[M]. 第二版. 北京: 清华大学出版社, 2006.

一些自己的想法（读者请略过）

• 命令至少包括两种：模式命令（切换到某种模式）和机器人控制命令（语音控制命令，被自然处理模块和空间推理模块处理）
• 人机交互界面应该在InputOperator操作者
• 命令解释器在算法服务部分，是机器人的高层大脑，具体执行动作的程序（来自机器人商业库）是底层大脑
• 考虑手动指令解析和语音指令解析并没有统一的方法，所以并不形成一个包含用例，而且这个包含用例太小了
• 是否应该改成“交互环境建模与展现”或者增加“交互环境建模”用例？（模仿 eyes 的鼠标拖动机器人进行定位）
• 自顶向下的类建模，并使用操作者框架，实际上一个ACTOR可以充当边界对象，控制对象
• 添加用例（命令非法警报用例，异常处理，错误恢复用例等）

用COMET解释LabVIEW Actor Framework（读者请略过）

• （什么是框架）
• 。。。。参考文献[3]
• （对操作者的解释）
• 实际上ACTOR类可以看作一个构件，该构件可以充当任何一种类或多种类（控制类，实体类，人机交互类，算法类等），并能很好地实现状态控制（采用其扩展功能State Pattern Actor），该构件内部集成了消息通信端口（支持点对点通信，不严格支持组播通信，且通信范围遵循任务树（Task Tree）），还支持TCP/IP远程通信。
• （操作者框架可实现的消息通信模式）
• 每一个ACTOR构件都是一个并发对象。ACTOR与ACTOR之间的通信模式可以是：带回复的同步（紧耦合）消息通信模式，异步（松耦合）消息通信模式，带回调的异步消息通信模式。另外，使用操作者框架还可以在面向服务的体系结构中实现代理者（Broker）通信模式。
• （从类图的角度来描述ACTOR类，是一个复合类）
• ACTOR类其实是个复合类，它还可以扩充自己的私有数据，即还可以包含更多（"Has A"）的类（现在的程序中没有包含更多的类，是因为我们自己的程序并不是使用面向对象方法设计的），所以在静态建模时，一个ACTOR应该是一个子系统，使用系统之系统。

正文：机器人远程协作系统建模与设计说明书

• 这是草稿！This IS A DRAFT!

问题描述

• 机器人监管者（Supervisor）在本地工作站上，通过无线局域网与远程的P3AT移动机器人（P3-AT Mobile Robot）进行协作，完成巡逻，环境监测，危险排除等任务。具体来讲，机器人监管者可以使用两种方式与机器人进行协作：手动控制（Manual Synergetic Control）和语音控制（Voice Synergetic Control），为了更好地与机器人进行协作，机器人在监管者面前应该是透明的，即机器人本体状态及周围环境信息应实时展现给监管者。
• 在手动控制中，监管者在本地工作站上使用操纵杆对机器人进行远程控制，监管者能够直接控制机器人自身移动，操作机械臂等执行机构，监管者也可以在地图上点击一个目标点，命令机器人到达该点位置；在语音交互中，监管者对手机讲述中文语音，将声音信号传递给机器人，机器人收到语音信号后执行对应的任务，如“向前走五米”命令。
• 机器人应做到较底层的行为自主，能够做到自我保护，环境识别与推理，路径规划等。机器人能够在较高的思维抽象层次与监管者进行协作。机器人在工作过程中，监管者能够随时打断机器人，获得最终控制权。
• 在监管者向机器人发送协作指令的同时，机器人将自身的状态信息和采集到的周围环境信息传输回本地工作站，本地工作站对其进行建模，通过人机交互界面将信息可视化。监管者在本地工作站上将能够清晰地了解机器人的情况。

用例模型

• 机器人远程协作系统用例模型如图所示，根据问题描述，该模型拥有两个参与者和四个用例（其中一个为包含的子用例）。系统中的人类参与者“监管者”负责发起所有用例，即“语音协作控制”、“手动协作控制”和“查看机器人状态”。由于所有用例均为人类参与者发起，外部系统参与者“P3-AT机器人”为次要参与者。
• 监管者通过输入输出设备与机器人进行协作，由于不管进行何种形式的协作控制，都需要先进行定位，所以“协作定位”用例作为“语音协作控制”和“手动协作控制”用例的包含用例。

//此处可以继续说明，将机器人参与者特殊化为执行器和传感器两个参与者

用例文档如下

“协作定位”用例

• 用例名：协作定位
• 概述：远程机器人结合对环境信息的推理以及监管者的提示对自身位置进行确定
• 参与者：监管者和P3-AT机器人
• 前置条件：工作站与机器人连接成功
• 主序列：
1. 系统检查当前定位是否有效
2. 如果当前定位无效，则开始交互定位。机器人自主对自身周围环境信息进行分析，推测自己的位置信息，包括高层信息（如在A513办公室）和底层信息（坐标信息），并反馈到工作站人机交互界面
3. 工作站结合机器人的状态信息，对信息进行分析，得到关于机器人状态的信息，反馈到工作站人机交互界面
4. 监管者结合反馈的信息，对信息进行确认或者修改，将最后确定的机器人位置信息传递给P3-AT机器人，定位成功，定位结束。
• 可替换序列：
• 步骤2：当前定位有效，定位成功定位结束。
• 步骤2-4：监管者无法确定机器人位置，取消定位，定位失败，定位结束。
• 后置条件：机器人定位成功。

“手动协作控制”用例

• 用例名：手动协作控制
• 概述：监管者在本地工作站，使用标准输入设备（键盘和鼠标）和游戏手柄输入设备对机器人进行远程控制。
• 参与者：监管者和P3-AT机器人
• 前置条件：工作站与机器人连接成功
• 主序列：
1. 机器人与监管者交互定位
2. 监管员要求进行手动协作控制，并选择控制模式：键盘控制、手柄控制或地图导引控制
3. 监管者操作标准输入设备和游戏手柄，将命令录入到本地工作站
4. 如果命令录入成功，本地工作站结合机器人状态数据，对命令进行初步分析，得到指令的抽象信息（类型，参数大小等），同时验证命令的合法性
5. 如果命令合法，本地工作站对命令进行解释，解释成机器人能够理解或直接执行的较底层指令
6. 如果解释成功，本地工作站将解释好的指令传递给远程机器人
7. 远程机器人对指令进行执行，并在人机交互界面显示命令执行情况
8. 如果命令执行情况正常，则在命令执行完毕后在人机交互界面显示执行结束情况
• 可替换序列：
• 步骤4：如果输入设备命令输入失败，工作站人机交互界面予以显示并停止，并要求监管者检查设备。
• 步骤5：如果命令不合法，工作站人机交互界面上予以显示并停止，并要求监管者修改或者重新输入命令
• 步骤6：如果命令解释失败，工作站人机交互界面上予以显示并停止，并要求监管者检查命令或重新输入命令
• 步骤8：如果命令执行过程中出现失败，工作站人机交互界面上予以显示并停止，并要求监管者重新输入命令。
• 步骤2-8：监管者放弃手动协作控制，控制结束。

“语音协作控制”用例

• 用例名：语音协作控制
• 概述：监管者在本地工作站，使用安卓手机输入语音信号，对机器人进行远程控制。
• 参与者：监管者和P3-AT机器人
• 前置条件：工作站与机器人连接成功
• 主序列：
1. 机器人与监管者交互定位
2. 监管员要求进行语音协作控制
3. 监管者使用手机输入进行语音信号录入，手机端将语音信号解释为中文命令，录入到本地工作站
4. 本地工作站结合机器人状态数据，对命令进行初步分析，得到指令的抽象信息（类型，参数大小等），验证命令的合法性
5. 如果命令合法，本地工作站对命令进行解释（翻译？），解释成机器人能够理解或直接执行的指令
6. 如果解释成功，本地工作站将解释好的指令传递给远程机器人
7. 远程机器人对指令进行执行，并在人机交互界面显示命令执行情况
8. 如果命令执行情况正常，则在命令执行完毕后在人机交互界面显示执行结束情况
• 可替换序列：
• 步骤5：如果命令不合法，工作站人机交互界面上予以显示并停止，并要求监管者修改或者重新输入命令
• 步骤6：如果命令解释失败，工作站人机交互界面上予以显示并停止，并要求监管者检查命令或重新输入命令
• 步骤8：如果命令执行过程中出现失败，则在人机交互界面上予以显示并停止，并要求监管者重新输入命令。
• 步骤2-8：监管者放弃语音协作控制，控制结束。

“查看机器人状态”用例

• 用例名：查看机器人状态
• 概述：机器人将周围环境信息和自身状态信息进行建模和分析，然后发送会本地工作站进行图形化显示，供监管者查看。
• 参与者：监管者和机器人
• 前置条件：工作站与机器人连接成功
• 主序列：
1. 监管者要求开启某项机器人传感器
2. 机器人检查自身完整性
3. 若机器人设备完好无损，则开始进行环境信息采集工作
4. 机器人结合自身的知识库或本体情况对采集到的环境信息进行分析，得出抽象状态信息
5. 如果抽象状态信息分析成功且有效，则将其传回本地工作站的人机交互界面。
6. 工作站的人机交互界面对信息进行可视化处理，形成友好的图形化数据。
• 可替换序列
• 步骤3：如果机器人某项设备损坏，则向工作站人机交互界面显示，要求监管者检查。
• 步骤5：如果抽象状态信息分析失败，则向工作站人机交互界面显示，要求调整。
• 步骤2-6：监管者关闭所有传感器，机器人状态查看退出。
• //对用例文档还要画出活动图

静态建模Static Model

• 本节先对问题域和系统上下文进行考虑，然后讨论实体类的静态建模。

问题域的概念静态模型Conceptual Static Model

• 图【】给出了用类图表示的概念静态模型。这里描述了一个系统之系统，包括“输入管理系统”，“全局协调系统”，“命令解析系统”，“执行管理系统”，“显示系统”。“输入管理系统”被建模为一个复合类，包括“手柄读入器”，“声音读入器”，“控制面板”类。
• 人类参与者通过手柄，声音输入设备，人机交互面板将协作命令输入到输入管理系统，输入管理系统通过全局协调系统与命令解析系统和执行管理系统联络，通过执行管理系统与外部的机器人参与者交互，同时机器人参与者将自身消息录入，通过全局协调系统与现实系统联络，显示机器人状态信息。
• 为了便于下一节建模，这里给出所有的物理类：。。。

系统上下文的静态建模Context Model

• 软件系统的上下文类图使用静态建模表示法，将“机器人协作系统”看作一个聚合类。描述了与“机器人协作系统”存在交互关系的外部类。我们通过考虑问题域的静态建模过程中所所确定的物理类来开发上下文类图。
• 如图所示，从整个系统（包括软件和硬件）的角度看，“监管者”和“机器人”参与者都位于系统外部。“监管者”参与者通过键盘显示器、手柄和声音输入设备与软件系统交互。“机器人”参与者作为外部系统直接与机器人协作软件系统交互。从整个软硬件系统的角度来说，这些通用或专用的输入输出设备是系统的一部分。从软件的角度来说，这个设备位于软件系统的外部。所以在软件系统的上下文类图中，这些设备被建模为外部类。
• 两个参与者都被建模为外部用户。
• 注意：显示系统根本就不是什么外部系统，建模为ACTOR，这个想法是错误的！要是都建模为外部系统，那还编什么程序，都在软件系统外部。

系统实体类建模（在显示控件中的数据是实体数据？？）

• 理解不够深刻，不知道怎么将操作者框架和COMET结合起来
• 初步的想法是，操作者框架中的消息就是存有数据的实体。（Message is the object）
• 实体类是概念性的数据密集型类——他们的主要目的是存储数据并提供对这些数据的访问。在许多情况下，实体类是持久的，这意味着数据是长久存在的，并需要存储在文件或者数据库中。实体类通常在设计阶段映射到一个数据库或文件。
• 为消息建模？

• 消息名称	从	到	在设计过程中分成了几个子消息	任务
  JoystickControlMsg	ExternalDevice	JoyStick Actor		读取
  	JoyStick Actor	InputOperator		直传
  	InputOperator	Cooradinator		直传
  	Cooradinator	P3AT		直传
  VoiceStringMsg	ExternalDevice	VoiceControl		读取
  VoiceControlMsg	VoiceControl	InputOperator		解析后传
  	InputOperator	Cooradinator		直传
  	Cooradinator	AgorithmService	(ServiceManager)	直传
  ExecutionMsg	AgorithmService	Cooradinator		解析后传
  	Cooradinator	OutputOperator		直传
  	OutputOperator	P3AT		解析后传
  P3ATRTData	ExternalDevice	P3AT
  	P3AT	OutputOperator
  	OutputOperator	MapDisplayer

• 考虑到，除了手柄控制消息之外，其他数据都是只发一次的按需发送消息（按需I/O），为了在致命错误时能够正常恢复数据，这些数据都应该作为持久数据以便进行恢复。
• 每一个实体类都包括大量属性，还有一些公共的属性，如：是否过期（有效）布尔值；（目前不确定）
• 所以，最终我们建了若干实体类，但是仍然有一些数据需要持久存储，比如P3AT机器人的IP地址和Port数据，这一部分还需进一步考虑
• 还需要画出类与类间的关系图，多重性关系，目前还不清楚，需要设计。
•  

对象组织（所有的函数/过程都应该成为类的方法！）

• 在定义了用例和开发了问题域的静态模型后，下一步是确定系统的软件对象。在这个阶段，重点在对问题域中真实世界对象进行建模的软件对象上。
• 软件对象是由用例和问题域的静态模型确定的。重点是在真实世界中发现的问题域对象，而不是在设计时确定的解域对象。
• 上一节中描述的静态建模被用来确定外部类，然后这些外部类会被描绘在软件系统上下文类图中。这些外部类会用来帮助确定软件边界类——连接到外部环境并与之通信的软件类。实体类及其关系也是在静态建模时确定的。本节中，软件系统所需要的对象和类被确定和分类。特别的，本节的焦点是那些在问题域静态建模期间没有被确定的附加的软件对象和类。
• （接下来的工作是审查LV代码，将所有的函数/过程都建模为类！）然后进行类和对象组织！

动态建模

子系统高层通信图

标签：命令,工作站,用例,机器人,建模,监管者,12.2,协作
来源： https://www.cnblogs.com/wanghuaijun/p/15415897.html