[openrtm-users 00843] Re: ステートマシンについての質問

2009年 6月 19日 (金) 01:54:02 JST

安藤様

ご解説ありがとうございます。

IDLや仕様を変えるのはハードルが高いので、
今の場合、ポートのコールバックポイントを
増やしていただければそれで充分です。

Inactive状態のdoアクションが欲しいと思った
のには、実はもう一つ理由がありました。
今のRTCモデルでは、Active状態からの終了処理は
onDeactivated()で実装し、それはただ一回の
コールで処理が完了する、というものかと思います。

ただ、現実には、終了処理時に外部のH/WやRTC等
と同期を取らなければならないことがよくあります。
そして、その同期は必ずしも任意のタイミングでは
出来ないため、終了処理が不完全に終わる可能性があります。

したがって、onDeactivated()が呼ばれた時に
実際の終了処理を遅延させる必要がでてくるのですが、
現状のステートマシンモデルではそれが想定されていない
ように思います。onDeactivated()が一度呼ばれると無条件で
Inactive状態になってしまい、Inactive状態では何の処理も
指定できないため、どうやっても終了処理を遅延させる
（再度onDeactivated()の処理を行う）ことができません。

もし、Inactive状態でdoアクションが実現できれば、
上記のような遅延処理も容易に実現できるかと思います。
また、別の方法として、ActiveとInactiveの間に
その中間状態を設けるという手もあるかと思います。
ただ、状態が増えるとその分モデルが複雑になるといった
トレードオフもあるので、悩むところです。
いずれにしろ、このようなものを実現するには、
RTC仕様や実装を大きく変更する必要があるので、
今は無理かと思います。他に良い手立てがあれば教えてくださ
い。

とりあえずは、onDeactivated()内でビジーループを作って
終了処理を遅延させることを考えています。
ただ、このような実装は明らかに望ましくないので、
スマートな実現方法が欲しいところです。

清水

--- Ando Noriaki <n-ando ＠ aist.go.jp> wrote:

> 清水様
> 
> 安藤です
> 
> おっしゃるような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<masayuki.shimizu ＠ aist.go.jp>
> さんは書きました:
> > 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処理をユーザが指定できる
> > ようにはならないのでしょうか？というのが
> > 私の質問です。
> >
> > 以上、よろしくご教授お願いいたします。
> >
> > 静岡大 清水
> >
> > --------------------
> > Masayuki Shimizu
> > Assistant Professor
> > Dept. of Mechanical Engineering, Shizuoka Univ.
> > 3-5-1, Johoku, Naka-ku, Hamamatsu 432-8561, JAPAN
> > TEL/FAX: +81-53-478-1061
> > Email: tmsimiz ＠ ipc.shizuoka.ac.jp
> >
> >
> 
> 
> 
> -- 
> 安藤慶昭＠独立行政法人産業技術総合研究所 研究員
>                   知能システム研究部門
> 統合知能研究グループ
>                   〒305-8568 茨城県つくば市梅園1-1-1
> 中央第2
>                   TEL: 029-861-5981 FAX:
> 029-862-6631
>                   n-ando ＠ aist.go.jp, n-ando ＠ ieee.org
> 
>