Pythonで書いた外部RTCがシミュレーション開始でアクティベートされない

[y-masutani]

#159 に関連していますが，別の話題と判断し新しいissueにします．

BodyRTCを使っている場合に，コントローラモジュールRTCとpythonで書いた外部RTCを接続した後に，シミュレーションを開始しましたが，BodyRTCとコントローラモジュールRTCはアクティベートされましたが，外部RTCはアクティベートされません．外部RTCを同じ仕様でC++で作り同じ設定で試すとアクティベートされます．

PythonとC++のコンポーネントでは何が違うのでしょうか？
PythonのRTCでもアクティベートされるようにするにはどうしたらいいのでしょうか？

[s-nakaoka]

PythonとC++のコンポーネントでは何が違うのでしょうか？
PythonのRTCでもアクティベートされるようにするにはどうしたらいいのでしょうか？

ごめんなさい、私の方では今のところ分かっておりませんで、この件回答することができません。どなたかご存知の方いらっしゃいますでしょうか？

とりあずこの件を当方の要調査事項に追加はしておきました。

[y-masutani]

先日，学会で原様に伺ったのですが，この原因はわかっているとのこと．OpenRTM-aistのPython版がバージョン1.1で仕様が変わったためだそうですが，口頭では詳細まで理解できませんでした．ユーザ側で対処できる方法があるようならば，具体的に教えていただけないでしょうか．よろしくお願いいたします．

[s-nakaoka]

どうも、PeriodicExecutionContextについて、C++でこれまでのバージョンではExtTrigExecutionContextServiceを継承していて、それを前提でOpenRTMPluginが組まれていた（実行コンテキストを内部で共通の型の変数に入れる必要があり、その共通の型がExtTrigExecutionContextServiceということで、その型にキャスト（narrow）して変数に入れていた）のですが、どうもPython版のOpenRTMではそうなっておらず、PeriodicExecutionContextはExecutionContextServiceからの継承となっていたようです。つまりC++版とPython版でExecutionContextの仕様が異なっていたということです。

それで、いずれにしてもどちらの実行コンテキストもExecutionContextServiceは継承していますので、その型の変数で保持すればよいではないかということになりました。

ちなみにOpenRTMの新しいバージョンではPython版と同じ仕様になるようです。

ユーザ側での対処ということになりますと、ExtTrigの方にするということになるかと思いますが、そうする周期実行でなくなってしまうので、それも困りますよね。

接続しているコンポーネントの自動アクティベーションの機能は、BodyRTCアイテム特有の機能なのですが、この機能は余計だったと思っており、いずれにしてもBodyRTCアイテムはBodyIoRTCアイテムで置き換えていきたく思っています。

そちらでは、ポートが接続されているからといって他のコンポーネントをアクティベートするようなことはせず、Choreonoid上でアイテムとして生成したRTCはシミュレーション開始時にactivateするが、そうでないRTCの状態を自動で変更することはしない、という方針となります。

[s-nakaoka]

ちなみに、

それで、いずれにしてもどちらの実行コンテキストもExecutionContextServiceは継承していますので、その型の変数で保持すればよいではないかということになりました。

については、近々開発版にて修正が入る予定です。それを使えば、Python版のコンポーネントもC++のものと同様に動くようになるはずです。