对Bhuman中模块的执行顺序的理解

原文网址：http://blog.csdn.net/lzf824446/article/details/7467633

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

不知道够不够详细, 如有不详细的, 可以与我联系.QQ:824446 

希望能够构建一个开放式交流学习氛围. 也算是另一种开源思想吧.

也可以留言到博客,  我会定期查看, 并更新问题.