清水様

安藤です

おっしゃるようなInactive時のdo処理は、0.2では存在
していましたが、OMGでの標準化のときにいろいろ議論があって
なくしてしまいました。

OMGのRTC仕様のPSMであるRTC.idlにおいて
ComponentActionのコールバックとしてInactive時の
コールバックが定義されていないので、ECがComponentAction
インターフェースをCORBAインターフェースとしてコールする限りは
実現するのは難しいでしょう。

ですが、おっしゃることを実現する方法は2つほど考えられます。
1. OMG RTCに対するOpenRTMの独自拡張として、
OpenRTM::CompoentAction::on_inactive() のように定義する。

　ただし、これは標準に準拠していないのであまりやりたくない方法ですね。
　あと、副作用としてCORBAのスタブがやたらと膨張するので
　そういう意味でもこの方法を採用するのには個人的には消極的です。

＃RTC::RTObjectはRTC::LwRTObjectとRTC::ComponentActionを継承しています。
＃ですので、OpenRTM::ComponentAction を利用するには、
# あらたに、RTC::LwRTObjectとOpenRTM::ComponentActionを
# 継承する OpenRTM::RTObject を定義しなければなりません。
＃しかしこうすると、使用しないRTC::RTObject等等のスタブも生成
＃されるので、libRTCのサイズがやたらと大きくなります。(+1MB弱ぐらい？)

2. 内部インターフェース関数としてon_inactive() を持たせ、
　owned_context のみにコールさせる。
CORBAインターフェースとしてon_inactive()を持たせるのは難しいですが、
単なる内部的な関数として追加することはできます。
owned_contextはRTCと通常同一プロセス内に存在するので、
RTCのCORBA以外の関数も呼ぶことができ、単なるクラスのメンバ関数
であるon_inactive()を呼ばせることができます。
ただし、呼べるのはowned_contextだけですので、複合RTC化する際に
owned_contextがとめられ、participating_contextのみで駆動される場合
on_inactive()をよぶコンテキストがなくなってしまいます。

あとは、第3の方法として、OMGに行きRTFを立ち上げRTCの仕様を変える
という手もあるにはあるのですが。いかがですか？＞清水さん

単に、ポートのコールバックの問題でしたら、RELEASE版までには直したいと思います。
ただ、構造が変わったために、OnWriteのように、フックするポイントが
非常に多くなってしまったので、利用者側が混乱しないかという心配がありました。
でも、コールバックが増えたからといって、必要がなければ使用しなけれすむだけ
ですので、いろいろなところにコールバックをセットできるように考えて見ます。

2009/06/18 15:29 に Masayuki Shimizu さんは書きました:
> RTC仕様に詳しい方へ
>
> RTCのステートマシンについて質問があるのですが、
> RTC仕様に詳しい方、教えてください。
>
> OpenRTM-aistのHPに載っている
> ステートマシン図を見る限りでは、
> Inactive状態にはentry/do/exitの
> どの処理も書いてないのですが、
> これは、いかなる処理もInactive状態では
> 許可しないということなのでしょうか？
>
> 通常、Inactive状態では何もすることがないため、
> それでもよいかなと思っていたのですが、
> 次のようなケースはどう実装するのがよいのか？
> というので悩んでいます。
>
> 【実現したいこと】
> RTCが外部イベントに応じて自己的に状態遷移をすること。
> 例えば、Inactive状態にあるRTCのデータ入力ポートに、
> ある特定のデータが入力されたら、自動的に
> Active状態に移行し、onExecuteの処理を行う。
>
> 【検討中の実現方法】
> (1) RTCとは別にイベント監視機構を導入する。
> (2) OpenRTM-aistで提供されるイベント通知機構の利用。
> (3) （RTC仕様違反でなければ）Inactive状態に
> do処理を実装する。
>
> (1)を実現するためには、監視用のスレッドを
> 自分で作り、周期的にイベントを監視する
> （ポーリングの場合）、という実装になるでしょうか。
> ただ、独自スレッドを上げるプログラムは、
> RTCの標準パターンにマッチしないし、
> リソースの面でも不利かと思います。
>
> (2)は、具体的には、データポートのコールバックを
> 利用する方法です。入力ポートにデータが
> 書き込まれると実行されるOnWrite系の処理内から
> ExecutionContext::activate_component()
> を呼んでやればよさそうです。
> ただ、OpenRTM-aist-1.0.0-RC1では、
> OnWriteコールバックは機能しないようですし、
> 0.4.2でも、OnWriteの呼ばれるタイミングに
> 少し問題があります。今の場合、
> バッファにデータを書き終わってからでないと
> 処理を開始できないので、バッファにデータを
> 書いた後に呼ばれるコールバックが欲しいのですが、
> 0.4.2では、すべてのOnWrite系はバッファに
> データが書かれる前に呼ばれてしまいます。
> したがって、現時点のOpenRTM-aistでは
> 実現に難があります。
>
> (3)が今回の質問に関連する方法です。
> 現在のOpenRTM-aistの実装では、
> Inactive状態でもdo処理に当たるものを
> 与えてあげれば、ECがそれを実行してくれる
> ように見受けられます。
> ただ、今のところ、そのコールバックが
> NULLに固定なので何も実行されないだけのようです。
> せっかく、周期的にECが動いているのに、
> そのリソースを利用しないのはもったいないと
> 感じます。そこで、もしRTC仕様違反でないなら、
> Inactive状態のdo処理をユーザが指定できる
> ようにはならないのでしょうか？というのが
> 私の質問です。
>
> 以上、よろしくご教授お願いいたします。
>
> 静岡大 清水