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

9 個の投稿 / 0 new
最終投稿
root
オフライン
Last seen: 7時間 47分 前
登録日: 2009-06-23 14:31
[openrtm-users 00011] RTコンポーネントの過渡状態のアクティビティオペレーションについて

稲村@IHIです。

>
> 親子の状態遷移を完全に一致させたい場合は、以前申し上げたような
> 同期複合コンポーネントを使用すれば、このようなことができると思います。
>

複数のコンポーネントの状態遷移を一致させるのであれば、この方法でよいと思います。
しかしながら、コンポーネントを設計していると、過渡状態でも時間のかかる処理を行なう
場面が想定されるので、doオペレーションが必要と考えました。
[openrtm-users 00009]は、その一例として、複数のコンポーネントを連携させる場合を
挙げましたがコンポーネント単体の処理でも必要ではないでしょうか。

>
> また、下位コンポーネントにたいして start, stop メッセージを
> 送るような処理は、コンポーネントではなく、アプリケーションプログラム
> から行うのではだめでしょうか?
>
コンポーネントを操作するアプリケーションプログラムという特別なものは存在せず、
コンポーネントのみで構成されるフレームワークを考えております。

未定義
root
オフライン
Last seen: 7時間 47分 前
登録日: 2009-06-23 14:31
[openrtm-users 00012] RTコンポーネントの過渡状態のアクティビティオペレーションについて

安藤@産総研です

ご意見ありがとうございます。>稲村さん

> 稲村@IHIです。
>
> >
> > 親子の状態遷移を完全に一致させたい場合は、以前申し上げたような
> > 同期複合コンポーネントを使用すれば、このようなことができると思います。
> >
>
> 複数のコンポーネントの状態遷移を一致させるのであれば、この方法でよいと思います。
> しかしながら、コンポーネントを設計していると、過渡状態でも時間のかかる処理を行なう
> 場面が想定されるので、doオペレーションが必要と考えました。
> [openrtm-users 00009]は、その一例として、複数のコンポーネントを連携させる場合を
> 挙げましたがコンポーネント単体の処理でも必要ではないでしょうか。

こちらでも、マニピュレータの初期化を rtc_starting_entry() で行っていますが、
初期姿勢に移行するまで待たせているので、3秒くらい STARTING 状態を
保持しています。

do がある処理=定常状態がある

ということになっていまして、ACTIVE, READY, ERROR, FATAL_ERROR が
定常状態がある状態ですので rtc_xxx_do() を用意しています。
さらに、定常状態では他の状態に遷移するために何らかのイベントが必要になります。
(原則として外部からのコマンド(オペレーション)呼び出しによって遷移します。)

現在は、
ACTIVE: rtc_start()
READY: rtc_stop()
ERROR: rtc_reset(), rtc_exit()
FATAL_ERROR: rtc_kill()

というようになっています。

逆に、外部からのオペレーション呼び出しに依らない状態遷移は
過渡状態ということになっています。

したがって、STARTING, STOPPING を定常状態にするということは、
新たに外部からのオペレーション呼び出しインターフェースを追加する
必要があります。
そうすると、これまでは rtc_start() 一発で ACTIVE 状態になっていたところを、
READY -> rtc_starting?() -> STARTING -> rtc_activate?() -> ACTIVE
のように2段階にしなければならず、またSTARTINGにdoがないようなコンポーネント
をACTIVE化するためにも2回のオペレーション呼び出しが必要になるのでは
ないでしょうか。
もしくは、rtc_starting?() で ACTIVE->STARTING->ACTIVE へと連続的に
変化させることもできるかとは思いますが、そうするとコンポーネント間で
状態遷移をあわせた意味が薄れてしまいます。

状態遷移はあくまでコンポーネントの状態遷移であって、
内部の処理の状態遷移とは分けて考えた方がいいのではないでしょうか?

コンポーネントはあくまで、アクティブ状態か非アクティブ状態があるだけで、
そのほかの状態はおまけのようなものと考えてください。

一応、現在のところこのようなルールで状態遷移を定めていますので、
rtc_starting_entry, rtc_stopping_entry で多少長い処理を行っても
いいのではないかと思います。

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

> > また、下位コンポーネントにたいして start, stop メッセージを
> > 送るような処理は、コンポーネントではなく、アプリケーションプログラム
> > から行うのではだめでしょうか?
> >
> コンポーネントを操作するアプリケーションプログラムという特別なものは存在せず、
> コンポーネントのみで構成されるフレームワークを考えております。

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

また、このMLをご覧の方でこういう意見をお持ちの方がいれば、
ぜひ議論に加わっていただきたいと思いますので、
よろしくお願いいたします。

root
オフライン
Last seen: 7時間 47分 前
登録日: 2009-06-23 14:31
[openrtm-users 00013] RTコンポーネントの過渡状態のアクティビティオペレーションについて

寺田@IHIです。はじめまして。

RTミドルウェアはほぼ素人ですが、
状態遷移モデリングの一般論として議論させてください。

> Subject: [openrtm-users 00012] Re: RTコンポーネントの過渡状態のアクティ
> ビティオペレーションについて
>
>
> 安藤@産総研です
>
<中略>

> こちらでも、マニピュレータの初期化を rtc_starting_entry() で行っていま
> すが、
> 初期姿勢に移行するまで待たせているので、3秒くらい STARTING 状態を
> 保持しています。
> do がある処理=定常状態がある
>
> ということになっていまして、ACTIVE, READY, ERROR, FATAL_ERROR が
> 定常状態がある状態ですので rtc_xxx_do() を用意しています。
> さらに、定常状態では他の状態に遷移するために何らかのイベントが必要にな
> ります。
> (原則として外部からのコマンド(オペレーション)呼び出しによって遷移します
> 。)

上記説明でよく分かりました(分かった気がします)。
稲村さんが言うように、物理的に長い時間かかる処理が必要であったとしても、
論理的には(RTミドルウェア仕様では)それは定常状態と見なさない、
ということですね。

過去に私も失敗した経験があるのですが、これは状態遷移設計の落とし穴の
一つと思います。処理時間の「長い・短い」は自明ではなく、
そのシステムの設計意図に依存している、
という点をついつい見逃してしまいがちです。

10秒かかる処理があろうとも、中断不能で後戻りしないと決めた
処理は、状態のアクティビティにしてはならない、という原則が
ここでも適用されている、ということで良いのでしょうか?

root
オフライン
Last seen: 7時間 47分 前
登録日: 2009-06-23 14:31
[openrtm-users 00014] RTコンポーネントの過渡状態のアクティビティオペレーションについて

安藤@産総研です

> 寺田@IHIです。はじめまして。

はじめまして。よろしくお願いいたします。

> RTミドルウェアはほぼ素人ですが、
> 状態遷移モデリングの一般論として議論させてください。

逆に、私の方は状態遷移モデリングに関してそれほど経験があるわけでは
ないので、いろいろと教えていただければ大変助かります。

> > 安藤@産総研です
> >
> <中略>
>
> > こちらでも、マニピュレータの初期化を rtc_starting_entry() で行っていま
> > すが、
> > 初期姿勢に移行するまで待たせているので、3秒くらい STARTING 状態を
> > 保持しています。
> > do がある処理=定常状態がある
> >
> > ということになっていまして、ACTIVE, READY, ERROR, FATAL_ERROR が
> > 定常状態がある状態ですので rtc_xxx_do() を用意しています。
> > さらに、定常状態では他の状態に遷移するために何らかのイベントが必要にな
> > ります。
> > (原則として外部からのコマンド(オペレーション)呼び出しによって遷移します
> > 。)
>
> 上記説明でよく分かりました(分かった気がします)。
> 稲村さんが言うように、物理的に長い時間かかる処理が必要であったとしても、
> 論理的には(RTミドルウェア仕様では)それは定常状態と見なさない、
> ということですね。

そうですね。RTコンポーネントで定義している状態遷移は、あくまで
論理単位としてのコンポーネントの状態遷移であって、その内部で
動作する具体的なロジックの状態遷移とは別ということです。

ただ、現在のRTコンポーネントでは、コンポーネント内部のロジックに
働きかける方法が、InPort/OutPortとrtc_start()等のコマンドインターフェース
しか用意されていないので、少し複雑なことをしようとすると、
行き詰ってしまうのかもしれません。

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

> 過去に私も失敗した経験があるのですが、これは状態遷移設計の落とし穴の
> 一つと思います。処理時間の「長い・短い」は自明ではなく、
> そのシステムの設計意図に依存している、
> という点をついつい見逃してしまいがちです。
>
> 10秒かかる処理があろうとも、中断不能で後戻りしないと決めた
> 処理は、状態のアクティビティにしてはならない、という原則が
> ここでも適用されている、ということで良いのでしょうか?

そうですね。凡そ、そのように考えて状態遷移を定義しました。

この件に関しては、産総研(2人)と共同研究者であった松下電工さん(2人)と、
いろいろな場面を想定して議論してきました。

ただし、その議論で全ての場合を網羅できてるとはいえないと思いますので、
こういった議論は大変重要であると思っております。

また、状態遷移の設計論に関して、参考になる本やWebページなどありましたら、
そのポインタだけでも教えていただければ幸いです。

root
オフライン
Last seen: 7時間 47分 前
登録日: 2009-06-23 14:31
[openrtm-users 00015] 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は一つだけでよい。
ただし、得られた状態データだけ見ても、どのコンポーネントから来たものか分からないので、
それを識別する仕組みを考える必要がある。

root
オフライン
Last seen: 7時間 47分 前
登録日: 2009-06-23 14:31
[openrtm-users 00016] RTコンポーネントの過渡状態のアクティビティオペレーションについて

> 稲村@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()というメソッドがありますので、それで各コンポーネントの
状態を取得できます。

root
オフライン
Last seen: 7時間 47分 前
登録日: 2009-06-23 14:31
[openrtm-users 00017] RTコンポーネントの過渡状態のアクティビティオペレーションについて

安藤様
ルメア@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

>
> > 稲村@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()というメソッドがありますので、それで各コンポーネントの
> 状態を取得できます。
>

root
オフライン
Last seen: 7時間 47分 前
登録日: 2009-06-23 14:31
[openrtm-users 00018] RTコンポーネントの過渡状態のアクティビティオペレーションについて

ルメア様

コメントありがとうございます。

> 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 ?

すみません。間違えました。

#include "RTCService.idl"

interface MyMobileRobot
: RTCService
{
void set_mode(int mode);
void brake(bool mode);
float get_battery_level();
};

MyMobileRobot は RTCService を継承します。

RTCServiceは以下のようになっています。

interface RTCService
{
attribute RTCServiceProfile profile;
};

ちなみに、RTCServiceProfile は以下のとおりです。
struct RTCServiceProfile
{
string name;
string interfaceType;
string idlDefinition;
NVList properties;
RTCService serviceRef;
};

ここで、RTCServiceProfile を RTCService に持たせるかどうか少し迷ったのですが、
RT-Middleware ではコンポーネントにできるだけ自分自身の情報を持たせて、
それ自身で完結するようにする方針を採っているので、その方針に従って
プロファイルをサービス自身に持たせました。

> 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.

たしかに、バッテリーに関してはOutPortのほうがよかったかもしれません。
何をインターフェースにして、何をOutPortやInPortにするかの判断は
むずかしいですね。
これは、あくまで実装側に任されているので、インターフェースや
フレームワークレベルでユーザに強要することはできません。
何かガイドライン的なものを示せるといいのですが。

root
オフライン
Last seen: 7時間 47分 前
登録日: 2009-06-23 14:31
[openrtm-users 00021] RTコンポーネントの過渡状態のアクティビティオペレーションについて

稲村@IHIです。
ずいぶん遅くなってしまいましたが、コメントさせていただきます。

>
> 単に、自分で定義したCORBAオブジェクトをコンポーネントに
> 持たせることができるようになっただけなんですが、
> オブジェクトの activation とか、名前でObjRef を取得
> するといった機能は提供しているので、生でCORBAで書くよりは
> すこしは楽かなとおもっています。
>
> ご意見あれば、お願いします。
>
よさそうな機能です。
例のような制御モードの切替とか、
ゲインの設定や、キネマティクス情報の設定などに使えると思います。

>
> class JoinComoenetsState
> {
> // 状態を監視したいコンポーネントを登録
> void add_component(RTCBase_ptr comp);
>
> // コンポーネント状態がstateになるまで待つ
> void join_state(RTComponentState state)
> };
>
> というようなヘルパークラスを作って、rtc_***_entry() や、
> rtc_***_exit() の最後
> でjoin_state() を実行するのではだめでしょうか?
>
>
> OutPortにはget()というメソッドがありますので、それで各コンポーネントの
> 状態を取得できます。
>
これは、InPortを使わずに、OutPortのオブジェクトリファレンスから
直接状態を取得すると言うことですね。なるほど。
どうも、ポートは接続して使うものと決め付けていました。
この方が良いと思います。

コメントを投稿するにはログインまたはユーザー登録を行ってください

ダウンロード

最新バージョン : 2.0.1-RELESE

統計

Webサイト統計
ユーザ数:2160
プロジェクト統計
RTコンポーネント307
RTミドルウエア35
ツール22
文書・仕様書2

Choreonoid

モーションエディタ/シミュレータ

OpenHRP3

動力学シミュレータ

OpenRTP

統合開発プラットフォーム

産総研RTC集

産総研が提供するRTC集

TORK

東京オープンソースロボティクス協会

DAQ-Middleware

ネットワーク分散環境でデータ収集用ソフトウェアを容易に構築するためのソフトウェア・フレームワーク