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