[openrtm-users 00015] Re: RTコンポーネントの過渡状態のアクティビティオペレーションについて

[稲村 渡]

稲村＠IHIです。

これまでの議論で、設計思想が把握できました。
そうであれば、私が想定していた状況では、今のままで問題ないと思います。
マニュアルにこういった説明も記述していただけたらありがたいです。

> [00012]
> もう少し具体的に rtc_starting_do が必要な例を示していただければ、
> OpenRTM-aist に必要な機能についていろいろ議論できると思います。

安藤さんが挙げていたように、デバイスの初期化や終了に時間が掛かる場合を考えていました。
制御データ（マニピュレータなら、各関節の速度など）とは別に、コマンドが欲しくなった場合、
現状では、ポートで受け渡しをすることになると思われます。（私は、そのように設計しました。）
他のコンポーネントからのコマンドをポートで受けて処理するのは、doオペレーションで行なうと
考えていたので、doがないと、過渡状態では、コンポーネントが応答しなくなってしまいます。
過渡状態なのだから、不要とすることもできますが、せめて、現在状態の問い合わせには
応答するべきと考えていました。
マニュアルを良く見ると、get_stateで、現在状態を出力するOutPortを取得できることがわかり、
この点は問題なくなります。
または、entryオペレーションで応答する処理をしても良いということになります。


> [00014]
> 現在、ユーザ定義のコマンドインターフェースを追加する方法を実装している
> ところでして、次のバージョンでは自分で定義したコマンドで、
> 内部の処理(RTコンポーネントのではなくて)の状態を変えたり、
> 内部で持っているパラメータを変えたりできるようになります。

これは、期待大です。
良かったら、どんな風になるのかもう少し具体的に教えてください。


> [00012]
> ただ、STARTING, STOPPING で他のコンポーネントとの待ち合わせを行いたいという
> ことであれば、それをサポートする機能は必要になってくるとは考えています。
> なにかいいアイディアがあれば教えてください。

すぐに思いつくのは、
待ち合わせを行なう関数をRtcBaseクラスに用意して、
コンポーネントを実装する派生クラスで、必要に応じて
rtc_***_entry()　や、rtc_***_exit() の最後で実行してもらうというものです。
深く検討していないので、落とし穴がありそうですが。

待ち合わせを行なう関数は、引数で待ち合わせを行ないたい相手の
コンポーネントのリストを受け取り、相手が全て、自分の現在状態でなくなるまで待つ。
そのために、RtcBaseには、状態を受け取れるInPortを追加し、
相手のコンポーネントのget_stateで状態を出力するOutPortを取得して接続する。
一つのInPortに複数のOutPortを接続することができるので、InPortは一つだけでよい。
ただし、得られた状態データだけ見ても、どのコンポーネントから来たものか分からないので、
それを識別する仕組みを考える必要がある。