【B-Human】之Module与Representation

Module从创建到运行的机制以及执行顺序是怎样的？

模块包含两个部分:requirements和representations.⼀个模块包含⼀个或多个requirements 和representations.

一个representation只能由一个模块更新.

在定义一个模块的时候他们分别使用宏REQUIRES 和PROVIDES进行添加到模块中.

motion(或者cognition)的moduleManager::update的主要作用就是将providers构造出来,也就是将属于motion(或者cognition)的真正模块创建出来. 在这里还将(shared)共享的部分提取出来了. 一是为了传递到sortProvider中作为算法的输入, 二是为了在使用simulator进行模块的调试时, 不同进程中的模块通信通过stream进行传递,机器人程序是线程的, 因此不需要考虑shared中的stream.(注: 在NAO上和在simulator中,motion与cognition都只是作为线程运行的)

sortProvider的作用就是将providers进行排序,解决模块之间的依赖关系.

如:A模块提供(PROVIDES)给B模块 representation.而A模块需要(REQUIRES)C模块的提供(PROVIDES)的representation.
则: 在providers中的整理后的顺序为: C--> A --> B

以上解决是仅仅是motion(或者cognition)中的模块之间的依赖关系. 也就是说, 模块的顺序, 是依靠representation的依赖关系来决定的. 大家可以仔细捉摸B-Human文档中的模块关系图, 再对照Modules中的每一个具体模块, 看一看模块的定义部分, 即可知道其中的奥妙. 

那motion线程与cognition线程之间的更新顺序又是如何的? 需要考虑吗?
    答:由于motion与cognition是作为线程运行的.motion运行速度为10ms运行⼀一次,cognition为33ms运行⼀一次. motion与cognition是并发运行的.当motion需要用到cognition的模块时, 直接使用即可, 因为此时可以保证,motion使用的在cognition中的模块一定是最新的数据.在整个进程框架中,motion与cognition之间并没有任何阻塞条件,他们之间是畅通无阻的. 而仅仅在调试或者作为进程实现的时候, 就必须通过timeStamp进行同步, 模块之间通过shared交流. 因此,motion与cognition之间的更新顺序就不需要考虑. 

注意: 整个process框架仅仅是为了调试或者实现进程而添加的.  因此, 在机器人上跑的程序是不需要考虑两个线程之间的同步问题.

setEventID仅仅设置时间条件. 到了一定的时间就切换. timeStamp也仅用于进程通信或者同步调试.

由此, 我们可知, B-Human已经保证了整个模块执行的顺序. 不需要考虑顺序问题. 仅仅去专注学习各个算法部分即可.

不得不佩服Thomas Rofer. 几乎整个底层工作全部是他一个人搭建的.  以及一些机器人中关键的算法理论部分(特别是运动控制这一块), 也是由他来设计的. 但我们也得坚信自己可以做到. 毕竟他的工作已经开展了有好几年了, 才有了现在的B-Human程序框架.