Actions
バグ #2315
closedOpenHRPExecutionContextにtick()をコールするdeactivate_component()を実装する。
Status:
終了
Priority:
通常
Assignee:
-
Target version:
-
Start date:
01/05/2012
Due date:
% Done:
100%
Estimated time:
Updated by kurihara almost 13 years ago
静岡大の清水です。 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()の呼び出し元でもあるため、 永遠に実際の状態遷移は起きず、タイムアウトエラーとなります。 この問題への対処法は、2つあると思います。 (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を採用した 時に困ることになると思いますので、よろしくご検討をお願いいたします。
Updated by n-ando almost 13 years ago
- Status changed from 新規 to 終了
- % Done changed from 0 to 100
Actions