OpenRTM-aist » OpenRTM-aist (C++)

静岡大の清水です。

PeriodicECのdeactivate_component()の挙動が、
バージョン1.1.0-RC3で、これまでの非同期からタイムアウト付き同期に
変更になっているようですが、これで困ったことが起きたのでご報告です。

当方では、OpenHRP3で行っているように、複数コンポーネントを、
SynchExtTriggerEC（実装名：OpenHRPExecutionContext）を使って同期させています。

バージョン1.0.0までは、PeriodicECのactivate/deactivate_component()メソッドは、
コンポーネントの実際の状態遷移とは非同期となっていたので、
activate/deactivate_component()の呼び出しは即座に返ってきました。

SynchExtTriggerECの場合は、その後で実際の状態遷移を起こすために、
tick()メソッドを明示的に呼び出しています。

ところが、deactivate_component()が実際の状態遷移と同期になっていると、
tick()の呼び出し元がdeactivate_component()の呼び出し元でもあるため、
永遠に実際の状態遷移は起きず、タイムアウトエラーとなります。

この問題への対処法は、２つあると思います。
(1) ECのdeactivate_component()内でtick()をコールする。
　PeriodicEC()のtick()実装は何もしないので、これによる問題は起きないはず。

(2) SynchExtTriggerECのdeactivate_component()を非同期呼び出しとして実装する。
　これは、1.0.0までの実装と同じ。

ちなみに、私は(2)の方法で問題を回避し、上手く動きました。

ここで、上記のどちらを採用するかは、RTCの仕様に依ると考えます。
RTCの仕様書では、deactivate_component()の挙動は、
状態遷移と同期なのか非同期なのか、どちらなのでしょうか。
（すいません。仕様書に詳しくないので。）

もし同期呼び出しなら、1.1.0の実装をPeriodicECには採用し、
SynchExtTriggerECのdeactivate_component()の実装ではtick()を呼ぶように
変更するのが妥当かと思います。
もし非同期なら、1.0.0までの実装を継承し、1.1.0の実装は元に戻すべきと思います。

この問題に対処しておかないと、OpenHRP3でバージョン1.1.0を採用した
時に困ることになると思いますので、よろしくご検討をお願いいたします。