“手动协作”用例
添加命令允许控制消息
- 具体来讲，在Input Operator Actor 的前面板中设置一些按钮，作为一个消息传递给Coordinator Actor ，由协调者操作者根据此控制簇来决定哪些命令应该被转发。
标准的操作者类应该是怎样的呢？
- 类的私有数据成员
- 将接受到的消息的数据类型引用输入控件
- 改变自己状态的用户事件句柄控件
- 类的前面板
- 接受到消息的数据类型的显示控件及引用
- 周期发送消息的循环
- 持续响应某事件的事件结构
- 改变自己状态，激发某用户事件即可
- 改变其他操作者状态，发送一次消息即可
- 对别人发过来的触发消息的响应，也在这儿
- 其他必要结构
- 启动子操作者，获取其队列
- 数据引用对类私有成员的初始化过程
- 操作者核心父方法
- 读取自己的和调用方的队列
考虑模式选择是用单选框还是复选框
- 三个布尔值如果是单选框，则只有三种情况，不用考虑怎样解释混合命令信号，实际上是一种枚举值。
- 但是如果作为复选框，则会存在很多种不同的命令混合情况，所以命令解释器的工作将会困难。比如三个布尔量，使用复选框将会有3+3+1=10中，命令解释器要考虑所有情况，必须使用更加高级的设计模式，如状态机，或者分层控制。
- 考虑到工作量，先按枚举值来吧
接下来更新地图
调试问题
- 程序开启机器人丢失
- 旋转方向是反的
- 点击地图显示控件工具栏也会触发事件结构，应该将工具栏移出去
接下来更新协调者，新建算法操作者
暂时不新建算法操作者，在协调者中进行运算得到
- 原因找到了，因为协调者虽然没有将P3AT控制消息发送过去，但P3AT其实一直对那个数据进行响应，即每隔10毫秒执行一次AriaDll.dll::drive.
- 解决方案：将外部控制簇发送到P3AT，P3AT根据外部控制簇进行响应。
- 还有一个问题是协调者的运行时菜单问题。
- 消息聚合问题
- 消息发送方式问题
- 发一次通过事件结构，还是周期性发送通过循环来响应？
- P3AT机器人在执行一些动作前应该确认执行条件，在执行开始前应该发出执行前信息，在执行完后应该发出确认信息和恢复信息
问题
- 第一次语音控制，正常执行之后，第二次语音控制，规划出来的数组依然以程序初始化的出生点为起点，因为每一次规划应该以当前点为起点。
- 能否抢占，实现更灵活的控制机制？
接下来几天的计划
- 将《软件建模与设计》看完，对整个协作系统有更深刻的理解
- 使用合适的软件体系结构解释协作系统
- 用例图
- 静态子系统图
- 子系统高层通信图和高层顺序图
- 使用正确的方法来设计和改进协作系统
- 使用软件工程的方法来解释LV-AF框架。