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

Olivier Lemaire olivier.lemaire @ aist.go.jp
2005年 8月 26日 (金) 10:07:48 JST


安藤様
ルメア@UFRGです。

今回英語で書きますが宜しくお願いいたします。
またご返事の希望の場合は日本語でもかまいません。

I basically agree with what you wrote, however, I have one question and one
comment concerning the MyMobileRobot interface :

> MyMobileRobot.idl (ロボットサービスのインターフェースを定義する)
> ------------------------------------------------------------
> #include "RTCService.idl"
>
> interface MyMobileRobot
> {
>   void set_mode(int mode);
>   void brake(bool mode);
>   float get_battery_level();
> };

Question : Why do you have to include RTCService.idl, Is it the base
interface of MyMobileRobot ?

Comment : In the case of the get_battery_level method, I would recommend to
use an OutPort instead because I am sure that in some application, you will
need the push capability of the OutPort to let other component know as soon
as possible that the Batteries are flat.
In general, I think that as far as access to data is concerned, you should
always use the OutPort (even if it's a bit heavier) because you never know
how the component will be used in the future.

Best Regards,

Olivier Lemaire

*−−−−−−−−−−−−−−−−−−−−−−−−*
* ルメア オリビエ (Olivier LEMAIRE)
*
* 独立行政法人産業技術総合研究所
* 知能システム研究部門
* 空間機能研究グループ
*
* 〒305−8568 茨城県つくば市梅園1−1−1 中央2
* TEL : 029−861−3494 
* FAX : 029−861−3493
* Email : Olivier.Lemaire@aist.go.jp
*−−−−−−−−−−−−−−−−−−−−−−−−*

>
> > 稲村@IHIです。
> >
> > これまでの議論で、設計思想が把握できました。
> > そうであれば、私が想定していた状況では、今のままで問題ないと思います。
> > マニュアルにこういった説明も記述していただけたらありがたいです。
>
> そうですね。次バージョンでは明記します。
> #0.2.0ではそこまで使い込んでくれる人は居ないのではないかと
> #思っていましたので...
> #逆に、こういう議論が出てきてこちらとしては大変助かります。
>
> > > [00012]
> > > もう少し具体的に rtc_starting_do が必要な例を示していただければ、
> > > OpenRTM-aist に必要な機能についていろいろ議論できると思います。
> >
> > 安藤さんが挙げていたように、デバイスの初期化や終了に時間が掛かる場合を考
> えていました。
> > 制御データ(マニピュレータなら、各関節の速度など)とは別に、コマンドが欲
> しくなった場合、
> > 現状では、ポートで受け渡しをすることになると思われます。(私は、そのよう
に
> 設計しました。)
> > 他のコンポーネントからのコマンドをポートで受けて処理するのは、doオペレー
> ションで行なうと
> > 考えていたので、doがないと、過渡状態では、コンポーネントが応答しなくなっ
> てしまいます。
> > 過渡状態なのだから、不要とすることもできますが、せめて、現在状態の問い合
> わせには
> > 応答するべきと考えていました。
> > マニュアルを良く見ると、get_stateで、現在状態を出力するOutPortを取得で
> きることがわかり、
> > この点は問題なくなります。
> > または、entryオペレーションで応答する処理をしても良いということになりま
> す。
>
> そうですね。アクティビティの作り方についてのガイドライン的なものは
> あった方がいいですね。今のところ、どう使おうがユーザの自由になっていますの
> で、
> 他の人が作ったコンポーネントを持ってきたときに、コンポーネントの
> 操作を統一できなくなってくるでしょうね。
> 足りないこと、できないことは、新たに機能を追加していきたいと思います。
>
> > > [00014]
> > > 現在、ユーザ定義のコマンドインターフェースを追加する方法を実装している
> > > ところでして、次のバージョンでは自分で定義したコマンドで、
> > > 内部の処理(RTコンポーネントのではなくて)の状態を変えたり、
> > > 内部で持っているパラメータを変えたりできるようになります。
> >
> > これは、期待大です。
> > 良かったら、どんな風になるのかもう少し具体的に教えてください。
>
> 簡単に言うと、ユーザ定義のオブジェクト(CORBAオブジェクト)をいくつか
> コンポーネントに持たせることができるようになります。
> ユーザはコンポーネントの内部状態(not アクティビティの状態)を
> そのオブジェクトのオペレーション経由で変えることができるようになります。
>
> 例えば、移動ロボットのコンポーネント(位置入力、速度入力、位置出力、速度出
力)
> のものがあるとします。
> これだけだと、外部からは位置、速度を入力して、位置、速度を取得する操作
> しかできません。(いまのRTコンポーネントではこうです。)
>
> この移動ロボットには、モード切替(速度制御、位置制御)、ブレーキON/OFF、
> バッテリー残量取得、などができる機能があったとします。
> InPort/OutPortでも制御できなくはないのですが、常にデータをやり取り
> する必要がないものばかりですので、InPort/OutPortは大げさすぎます。
>
>
> MyMobileRobot.idl (ロボットサービスのインターフェースを定義する)
> ------------------------------------------------------------
> #include "RTCService.idl"
>
> interface MyMobileRobot
> {
>   void set_mode(int mode);
>   void brake(bool mode);
>   float get_battery_level();
> };
>
> MyMobileRobot_imple.h (ロボットサービスを実装する)
> ------------------------------------------------------------
> #include "MyMobileRobot.h"
>
> class MyMobileRobot_imple
>  : public virtual POA_MyMobileRobot,
>    public virtual RtcServiceBase
> {
>   void set_mode(int mode){your code};
>   void brake(bool mode){your code};
>   float get_battery_level(){your code};
> };
>
>
> MobileRobot.h (コンポーネントのソース: コンポーネントのコンストラクタで登
> 録)
> ------------------------------------------------------------
> class MobileRobot
>  : RtcBase
> {
>  public:
>   MobileRobot()
>    :初期化子
>   {
>       RtcServiceProfile profile("MyMobileRobot", "MyMobileRobot",
>                                  MyMobileRobot_idl_def);
>       registerService(m_MyMobileRobot, profile);
>
>         :
>         :
>   }
>
>         :
>         :
>
>  protected:
>   // InPort/OutPort declaration
>       :
>   // Service declaration
>   MyMobileRobot_imple m_MyMobileRobot;
>
> };
>
>
> クライアントコード
> ------------------------------------------------------------
> comp = 何らかの方法でコンポーネントのObjRefを取得
> RTCService_var service = comp->get_service("MyMobileRobot");
> MyMobileRobot_var myrobo = MyMobileRobot::_narrow(service);
>
> // 取得したサービスを利用する
> myrobo->set_mode(mode);
> myrobo->brake(true);
> float level = myrobo->get_battery_lebel();
>
>
>
>
> 大体こんな感じです。
> (何もみないで書いたので細かい間違いはご容赦を。。。)
>
> 単に、自分で定義したCORBAオブジェクトをコンポーネントに
> 持たせることができるようになっただけなんですが、
> オブジェクトの activation とか、名前でObjRef を取得
> するといった機能は提供しているので、生でCORBAで書くよりは
> すこしは楽かなとおもっています。
>
> ご意見あれば、お願いします。
>
> > > [00012]
> > > ただ、STARTING, STOPPING で他のコンポーネントとの待ち合わせを行いたい
と
> いう
> > > ことであれば、それをサポートする機能は必要になってくるとは考えていま
す。
> > > なにかいいアイディアがあれば教えてください。
> >
> > すぐに思いつくのは、
> > 待ち合わせを行なう関数をRtcBaseクラスに用意して、
> > コンポーネントを実装する派生クラスで、必要に応じて
> > rtc_***_entry() や、rtc_***_exit() の最後で実行してもらうというもので
す。
> > 深く検討していないので、落とし穴がありそうですが。
>
> それだけでしたら、
>
> class JoinComoenetsState
> {
>   // 状態を監視したいコンポーネントを登録
>   void add_component(RTCBase_ptr comp);
>
>   // コンポーネント状態がstateになるまで待つ
>   void join_state(RTComponentState state)
> };
>
> というようなヘルパークラスを作って、rtc_***_entry() や、rtc_***_exit() の
> 最後
> でjoin_state() を実行するのではだめでしょうか?
>
> > 待ち合わせを行なう関数は、引数で待ち合わせを行ないたい相手の
> > コンポーネントのリストを受け取り、相手が全て、自分の現在状態でなくなるま
> で待つ。
> > そのために、RtcBaseには、状態を受け取れるInPortを追加し、
> > 相手のコンポーネントのget_stateで状態を出力するOutPortを取得して接続す
> る。
> > 一つのInPortに複数のOutPortを接続することができるので、InPortは一つだ
> けでよい。
> > ただし、得られた状態データだけ見ても、どのコンポーネントから来たものか分
> からないので、
> > それを識別する仕組みを考える必要がある。
>
> OutPortにはget()というメソッドがありますので、それで各コンポーネントの
> 状態を取得できます。
>
>           安藤慶昭@独立行政法人産業技術総合研究所 研究員
>                     知能システム研究部門 タスクインテリジェンス研究グルー
>>                     〒305-8568 茨城県つくば市梅園1-1-1 中央第2
>                     TEL: 029-861-5981 FAX: 029-861-5971
>                     n-ando @ aist.go.jp, n-ando @ ieee.org




openrtm-users メーリングリストの案内