[openrtm-users 00039] RTコンポーネントとプロセスの関係について

7 個の投稿 / 0 new
最終投稿
root
オフライン
Last seen: 1日 11時間 前
登録日: 2009-06-23 14:31
[openrtm-users 00039] RTコンポーネントとプロセスの関係について

はじめまして。宇田@NECシステムテクノロジーと申します。

OpenRTMコンポーネントとプロセスの関係について、少し詳しく教えて
頂けますでしょうか?

例えば既存のロボット用のソフトウェア資産をOpenRTMで活用する場合、
普通に考えると頭、腕、足などのパーツごとにコンポーネント化するの
が自然かと思います。

OpenRTMから見たロボットソフトウェア
+---------------------------------------------+
| システム |
| +-----------+ +-----------+ +-----------+ |
| | 頭制御 | | 腕制御 | | 足制御 | |
| | Component | | Component | | Component | |
| +-----------+ +-----------+ +-----------+ |
+---------------------------------------------+

これらのパーツの制御用ソフトウェアは、元々がロボット・システムで
あるという経緯から、通常は1プロセス内で動いていることが想定され
ます。

ロボットソフトウェアの内部構造
+---------------------------------------------+
| 単一プロセス |
| +-----------+ +-----------+ +-----------+ |
| | 頭制御部 | | 腕制御部 | | 足制御部 | |
| +-----------+ +-----------+ +-----------+ |
+---------------------------------------------+

そこで、最も簡単なコンポーネント化の方法は、これら3種類のコンポー
ネントを1つの実行ファイルにまとめる方法かと思うのですが、デベロッ
パーズガイドの3.1.1.1によると、スタンドアロンコンポーネントは原則と
して1プロセスにつき1種類のコンポーネントにのみ対応するとあります。
これは何か技術的な理由による制約でしょうか?

またローダブルモジュールコンポーネントであれば複数種類のコンポーネ
ントに対応可能なようですが、それらのロード先を1プロセスに制限する
ことは可能でしょうか?(上記のように、ベースになるソフトウェア資産
が単一プロセスで動いている場合、それを基に作成したコンポーネントも
同一プロセス内で動かすのが最もシンプルかと思うのですが)

コンポーネントサーバがこのロード・実行の役割を担っているようですが、
デベロッパーズガイドにはあまり解説がないようですので、もし関連する
資料などがありましたら公開して頂けると助かります。

ご検討の程よろしくお願い致します。

未定義
root
オフライン
Last seen: 1日 11時間 前
登録日: 2009-06-23 14:31
[openrtm-users 00040] RTコンポーネントとプロセスの関係について

宇田様

> はじめまして。宇田@NECシステムテクノロジーと申します。

はじめまして
安藤@産総研です

> OpenRTMコンポーネントとプロセスの関係について、少し詳しく教えて
> 頂けますでしょうか?
>
> 例えば既存のロボット用のソフトウェア資産をOpenRTMで活用する場合、
> 普通に考えると頭、腕、足などのパーツごとにコンポーネント化するの
> が自然かと思います。
>
> OpenRTMから見たロボットソフトウェア
> +---------------------------------------------+
> | システム |
> | +-----------+ +-----------+ +-----------+ |
> | | 頭制御 | | 腕制御 | | 足制御 | |
> | | Component | | Component | | Component | |
> | +-----------+ +-----------+ +-----------+ |
> +---------------------------------------------+
>
> これらのパーツの制御用ソフトウェアは、元々がロボット・システムで
> あるという経緯から、通常は1プロセス内で動いていることが想定され
> ます。
>
> ロボットソフトウェアの内部構造
> +---------------------------------------------+
> | 単一プロセス |
> | +-----------+ +-----------+ +-----------+ |
> | | 頭制御部 | | 腕制御部 | | 足制御部 | |
> | +-----------+ +-----------+ +-----------+ |
> +---------------------------------------------+
>
> そこで、最も簡単なコンポーネント化の方法は、これら3種類のコンポー
> ネントを1つの実行ファイルにまとめる方法かと思うのですが、デベロッ
> パーズガイドの3.1.1.1によると、スタンドアロンコンポーネントは原則と
> して1プロセスにつき1種類のコンポーネントにのみ対応するとあります。
> これは何か技術的な理由による制約でしょうか?

そのようなコンポーネントをスタンドアロンコンポーネントと呼んでいるだけです。

> またローダブルモジュールコンポーネントであれば複数種類のコンポーネ
> ントに対応可能なようですが、それらのロード先を1プロセスに制限する
> ことは可能でしょうか?(上記のように、ベースになるソフトウェア資産
> が単一プロセスで動いている場合、それを基に作成したコンポーネントも
> 同一プロセス内で動かすのが最もシンプルかと思うのですが)

rtc-template で作成されるスタンドアロンコンポーネント("なんとかComp.cpp")は、
あくまで一例で、当該コンポーネントを1個だけ作成するための実行ファイルです。

全部のコンポーネントを同じプロセスで動かしたい場合、
同一のマネージャでそれらのコンポーネントを作成すれば可能です。

仮に、上記の3つのコンポーネントが下記のようなソースからできているとします。
Head.cpp, Head.h, HeadComp.cpp
Arm.cpp, Arm.h, ArmComp.cpp
Leg.cpp, Leg.h, LegComp.cpp

ここで、全部のコンポーネントをいっぺんに作成する新しい
実行ファイル (AllComp) を作成します。
------------------------------------------------------------
AllComp.cpp
------------------------------------------------------------
#include
#include "Head.h"
#include "Arm.h"
#include "Leg.h"

// この関数は、main 無いの、manager.initModuleProc(MyModuleInit) で
// 一度だけ実行される。
void MyModuleInit(RtcManager* manager)
{
HeadInit(manager); // Head.h 内に定義されている。
ArmInit(manager); // Arm.h 内に定義されている。
LegInit(manager); // Leg.h 内に定義されている。

std::string name;
// コンポーネントを作成する
// Headコンポーネント: 名前 "Head", カテゴリ "Generic" とする。
manager->createComponent("Head", "Generic", name);
// Armコンポーネント: 名前 "Arm", カテゴリ "Generic" とする。
manager->createComponent("Arm", "Generic", name);
// Legコンポーネント: 名前 "Leg", カテゴリ "Generic" とする。
manager->createComponent("Leg", "Generic", name);

return;
}

int main ()
: つづく
------------------------------------------------------------

これを、Head.o, Arm.o, Leg.o とリンクすれば、
ご希望の実行ファイルになると思います。

実は、もう少し柔軟な方法もあります。
コンポーネントをビルドすると、Head.so, Arm.so, Leg.so
といった共有オブジェクトファイルも一緒に作成されますが、
これを使うこともできます。

------------------------------------------------------------
AllComp.cpp
------------------------------------------------------------
#include

void MyModuleInit(RtcManager* manager)
{
// 共有ライブラリをロード
manager->load("Head.so", "HeadInit");
manager->load("Arm.so", "ArmInit");
manager->load("Leg.so", "LegInit");

std::string name;
// コンポーネントを作成する
manager->createComponent("Head", "Generic", name);
manager->createComponent("Arm", "Generic", name);
manager->createComponent("Leg", "Generic", name);

return;
}

int main ()
: つづく
------------------------------------------------------------

このように、マネージャにsoファイルをロードさせて、
コンポーネントを作成することもできます。

あまり違いがないように見えますが、こちらの方法では、
Head.h, Arm.h, Leg.h をincludeしていません。

この方法だと、どれかひとつのコンポーネントに変更があっても、
この実行ファイルをコンパイル・リンクしなおす必要がありません。

> コンポーネントサーバがこのロード・実行の役割を担っているようですが、
> デベロッパーズガイドにはあまり解説がないようですので、もし関連する
> 資料などがありましたら公開して頂けると助かります。

今のところ、公開できるような資料はありませんが、
付属のクラスリファレンス RTM::RtcManager の項を読んでいただければ、
おそらくお分かりになるのではないかと思います。

次のバージョンのマニュアルでは、使い方等記載しようと考えております。

root
オフライン
Last seen: 1日 11時間 前
登録日: 2009-06-23 14:31
[openrtm-users 00041] RTコンポーネントとプロセスの関係について

いつも御世話になります。宇田@NECシステムテクノロジーです

どうも詳細な情報をありがとうございます。

コンポーネントとプロセスの関係がだいぶイメージできました。

もう一点、RTCLinkとコンポーネントの関係について教えて頂い
てもよろしいでしょうか?

デベロッパーズガイドの2.3項を拝見しますと、ConsoleInCompと
ConsoleOutCompのプロセスを起動したのち、RTCLinkのシステム
ドローウィンドウの中でもConsoleIn/Outのコンポーネントを
ドラッグ&ドロップしてStartさせているようですが、この時の
両コンポーネントは、ConsoleIn/OutCompとRTCLinkのどちらの
プロセス下で稼動しているのでしょうか?

またConsoleInCompの中でもmanager->createComponent()により
コンポーネントのインスタンスを生成しているようですが、これ
とRTCLinkのシステムドローウィンドウのコンポーネントは同一
インスタンスなのでしょうか、それとも別物でしょうか?

> 宇田様
>
> > はじめまして。宇田@NECシステムテクノロジーと申します。
>
> はじめまして
> 安藤@産総研です
>
> > OpenRTMコンポーネントとプロセスの関係について、少し詳しく教えて
> > 頂けますでしょうか?
> >
> > 例えば既存のロボット用のソフトウェア資産をOpenRTMで活用する場合、
> > 普通に考えると頭、腕、足などのパーツごとにコンポーネント化するの
> > が自然かと思います。
> >
> > OpenRTMから見たロボットソフトウェア
> > +---------------------------------------------+
> > | システム |
> > | +-----------+ +-----------+ +-----------+ |
> > | | 頭制御 | | 腕制御 | | 足制御 | |
> > | | Component | | Component | | Component | |
> > | +-----------+ +-----------+ +-----------+ |
> > +---------------------------------------------+
> >
> > これらのパーツの制御用ソフトウェアは、元々がロボット・システムで
> > あるという経緯から、通常は1プロセス内で動いていることが想定され
> > ます。
> >
> > ロボットソフトウェアの内部構造
> > +---------------------------------------------+
> > | 単一プロセス |
> > | +-----------+ +-----------+ +-----------+ |
> > | | 頭制御部 | | 腕制御部 | | 足制御部 | |
> > | +-----------+ +-----------+ +-----------+ |
> > +---------------------------------------------+
> >
> > そこで、最も簡単なコンポーネント化の方法は、これら3種類のコンポー
> > ネントを1つの実行ファイルにまとめる方法かと思うのですが、デベロッ
> > パーズガイドの3.1.1.1によると、スタンドアロンコンポーネントは原則と
> > して1プロセスにつき1種類のコンポーネントにのみ対応するとあります。
> > これは何か技術的な理由による制約でしょうか?
>
> そのようなコンポーネントをスタンドアロンコンポーネントと呼んでいるだけです。
>
> > またローダブルモジュールコンポーネントであれば複数種類のコンポーネ
> > ントに対応可能なようですが、それらのロード先を1プロセスに制限する
> > ことは可能でしょうか?(上記のように、ベースになるソフトウェア資産
> > が単一プロセスで動いている場合、それを基に作成したコンポーネントも
> > 同一プロセス内で動かすのが最もシンプルかと思うのですが)
>
> rtc-template で作成されるスタンドアロンコンポーネント("なんとかComp.cpp")は、
> あくまで一例で、当該コンポーネントを1個だけ作成するための実行ファイルです。
>
> 全部のコンポーネントを同じプロセスで動かしたい場合、
> 同一のマネージャでそれらのコンポーネントを作成すれば可能です。
>
> 仮に、上記の3つのコンポーネントが下記のようなソースからできているとします。
> Head.cpp, Head.h, HeadComp.cpp
> Arm.cpp, Arm.h, ArmComp.cpp
> Leg.cpp, Leg.h, LegComp.cpp
>
> ここで、全部のコンポーネントをいっぺんに作成する新しい
> 実行ファイル (AllComp) を作成します。
> ------------------------------------------------------------
> AllComp.cpp
> ------------------------------------------------------------
> #include
> #include "Head.h"
> #include "Arm.h"
> #include "Leg.h"
>
> // この関数は、main 無いの、manager.initModuleProc(MyModuleInit) で
> // 一度だけ実行される。
> void MyModuleInit(RtcManager* manager)
> {
> HeadInit(manager); // Head.h 内に定義されている。
> ArmInit(manager); // Arm.h 内に定義されている。
> LegInit(manager); // Leg.h 内に定義されている。
>
> std::string name;
> // コンポーネントを作成する
> // Headコンポーネント: 名前 "Head", カテゴリ "Generic" とする。
> manager->createComponent("Head", "Generic", name);
> // Armコンポーネント: 名前 "Arm", カテゴリ "Generic" とする。
> manager->createComponent("Arm", "Generic", name);
> // Legコンポーネント: 名前 "Leg", カテゴリ "Generic" とする。
> manager->createComponent("Leg", "Generic", name);
>
> return;
> }
>
> int main ()
> : つづく
> ------------------------------------------------------------
>
> これを、Head.o, Arm.o, Leg.o とリンクすれば、
> ご希望の実行ファイルになると思います。
>
>
> 実は、もう少し柔軟な方法もあります。
> コンポーネントをビルドすると、Head.so, Arm.so, Leg.so
> といった共有オブジェクトファイルも一緒に作成されますが、
> これを使うこともできます。
>
> ------------------------------------------------------------
> AllComp.cpp
> ------------------------------------------------------------
> #include
>
> void MyModuleInit(RtcManager* manager)
> {
> // 共有ライブラリをロード
> manager->load("Head.so", "HeadInit");
> manager->load("Arm.so", "ArmInit");
> manager->load("Leg.so", "LegInit");
>
> std::string name;
> // コンポーネントを作成する
> manager->createComponent("Head", "Generic", name);
> manager->createComponent("Arm", "Generic", name);
> manager->createComponent("Leg", "Generic", name);
>
> return;
> }
>
> int main ()
> : つづく
> ------------------------------------------------------------
>
> このように、マネージャにsoファイルをロードさせて、
> コンポーネントを作成することもできます。
>
> あまり違いがないように見えますが、こちらの方法では、
> Head.h, Arm.h, Leg.h をincludeしていません。
>
> この方法だと、どれかひとつのコンポーネントに変更があっても、
> この実行ファイルをコンパイル・リンクしなおす必要がありません。
>
> > コンポーネントサーバがこのロード・実行の役割を担っているようですが、
> > デベロッパーズガイドにはあまり解説がないようですので、もし関連する
> > 資料などがありましたら公開して頂けると助かります。
>
> 今のところ、公開できるような資料はありませんが、
> 付属のクラスリファレンス RTM::RtcManager の項を読んでいただければ、
> おそらくお分かりになるのではないかと思います。
>
> 次のバージョンのマニュアルでは、使い方等記載しようと考えております。
>

root
オフライン
Last seen: 1日 11時間 前
登録日: 2009-06-23 14:31
[openrtm-users 00042] RTコンポーネントとプロセスの関係について

宇田様

安藤@産総研です

> いつも御世話になります。宇田@NECシステムテクノロジーです
> どうも詳細な情報をありがとうございます。
>
> コンポーネントとプロセスの関係がだいぶイメージできました。
>
> もう一点、RTCLinkとコンポーネントの関係について教えて頂い
> てもよろしいでしょうか?
>
> デベロッパーズガイドの2.3項を拝見しますと、ConsoleInCompと
> ConsoleOutCompのプロセスを起動したのち、RTCLinkのシステム
> ドローウィンドウの中でもConsoleIn/Outのコンポーネントを
> ドラッグ&ドロップしてStartさせているようですが、この時の
> 両コンポーネントは、ConsoleIn/OutCompとRTCLinkのどちらの
> プロセス下で稼動しているのでしょうか?

RTCLinkとコンポーネントは別のプロセスで動いています。
RTCLinkは単にコンポーネントの状態を表示したり、
コンポーネントにコマンドを送るためだけのツールです。

RTCLinkはコンポーネントと同じPCで実行する必要もありません。
ネットワークでつながっており、同じネームサーバを参照していれば、
RTCLinkからネットワーク上のどのコンポーネントでも操作することができます。

> またConsoleInCompの中でもmanager->createComponent()により
> コンポーネントのインスタンスを生成しているようですが、これ
> とRTCLinkのシステムドローウィンドウのコンポーネントは同一
> インスタンスなのでしょうか、それとも別物でしょうか?

システムドローウインドウ上の箱は、コンポーネントの
状態やポートの数を表すためのもので、コンポーネント自体が、
RTCLink上で動いているわけではありません。

root
オフライン
Last seen: 1日 11時間 前
登録日: 2009-06-23 14:31
[openrtm-users 00043] RTコンポーネントとプロセスの関係について

いつも御世話になります。宇田@NECシステムテクノロジーです

> 宇田様
>
> 安藤@産総研です
>
> > いつも御世話になります。宇田@NECシステムテクノロジーです
> > どうも詳細な情報をありがとうございます。
> >
> > コンポーネントとプロセスの関係がだいぶイメージできました。
> >
> > もう一点、RTCLinkとコンポーネントの関係について教えて頂い
> > てもよろしいでしょうか?
> >
> > デベロッパーズガイドの2.3項を拝見しますと、ConsoleInCompと
> > ConsoleOutCompのプロセスを起動したのち、RTCLinkのシステム
> > ドローウィンドウの中でもConsoleIn/Outのコンポーネントを
> > ドラッグ&ドロップしてStartさせているようですが、この時の
> > 両コンポーネントは、ConsoleIn/OutCompとRTCLinkのどちらの
> > プロセス下で稼動しているのでしょうか?
>
> RTCLinkとコンポーネントは別のプロセスで動いています。
> RTCLinkは単にコンポーネントの状態を表示したり、
> コンポーネントにコマンドを送るためだけのツールです。
>
> RTCLinkはコンポーネントと同じPCで実行する必要もありません。
> ネットワークでつながっており、同じネームサーバを参照していれば、
> RTCLinkからネットワーク上のどのコンポーネントでも操作することができます。
>
> > またConsoleInCompの中でもmanager->createComponent()により
> > コンポーネントのインスタンスを生成しているようですが、これ
> > とRTCLinkのシステムドローウィンドウのコンポーネントは同一
> > インスタンスなのでしょうか、それとも別物でしょうか?
>
> システムドローウインドウ上の箱は、コンポーネントの
> 状態やポートの数を表すためのもので、コンポーネント自体が、
> RTCLink上で動いているわけではありません。

了解致しました。どうもありがとうございます。

では、RTCLink上でコンポーネントを生成・起動する場合、実際に
はその生成・起動要求が上記のConsoleXXCompのプロセスに渡され、
そのプロセス下でコンポーネントのインスタンスが生成・起動され
るという解釈でよろしいでしょうか?

その場合、ConsoleXXCompのMyModuleInitの中でcreateComponent
により生成しているインスタンスと、RTCLink上で新たにドラッグ
&ドロップしたコンポーネントのインスタンスとは別物になるの
でしょうか?

root
オフライン
Last seen: 1日 11時間 前
登録日: 2009-06-23 14:31
[openrtm-users 00044] RTコンポーネントとプロセスの関係について

宇田様

安藤@産総研です

> > RTCLinkとコンポーネントは別のプロセスで動いています。
> > RTCLinkは単にコンポーネントの状態を表示したり、
> > コンポーネントにコマンドを送るためだけのツールです。
> >
> > RTCLinkはコンポーネントと同じPCで実行する必要もありません。
> > ネットワークでつながっており、同じネームサーバを参照していれば、
> > RTCLinkからネットワーク上のどのコンポーネントでも操作することができます。
> >
> > > またConsoleInCompの中でもmanager->createComponent()により
> > > コンポーネントのインスタンスを生成しているようですが、これ
> > > とRTCLinkのシステムドローウィンドウのコンポーネントは同一
> > > インスタンスなのでしょうか、それとも別物でしょうか?
> >
> > システムドローウインドウ上の箱は、コンポーネントの
> > 状態やポートの数を表すためのもので、コンポーネント自体が、
> > RTCLink上で動いているわけではありません。
>
> 了解致しました。どうもありがとうございます。
>
> では、RTCLink上でコンポーネントを生成・起動する場合、実際に
> はその生成・起動要求が上記のConsoleXXCompのプロセスに渡され、
> そのプロセス下でコンポーネントのインスタンスが生成・起動され
> るという解釈でよろしいでしょうか?

RTCLink上で、ネームウインドウからドローウインドウにDnDすることによって、
コンポーネントのインスタンスが生成されることはありません。

ネームツリー上の、例えば ConsoleIn0|rtc という名前は、
すでに生成されているコンポーネントのインスタンスに対応します。

> その場合、ConsoleXXCompのMyModuleInitの中でcreateComponent
> により生成しているインスタンスと、RTCLink上で新たにドラッグ
> &ドロップしたコンポーネントのインスタンスとは別物になるの
> でしょうか?

ですので同じものです。

お分かりいただけたでしょうか?

root
オフライン
Last seen: 1日 11時間 前
登録日: 2009-06-23 14:31
[openrtm-users 00045] RTコンポーネントとプロセスの関係について

いつも御世話になります。宇田@NECシステムテクノロジーです

> 宇田様
>
> 安藤@産総研です
>
> > > RTCLinkとコンポーネントは別のプロセスで動いています。
> > > RTCLinkは単にコンポーネントの状態を表示したり、
> > > コンポーネントにコマンドを送るためだけのツールです。
> > >
> > > RTCLinkはコンポーネントと同じPCで実行する必要もありません。
> > > ネットワークでつながっており、同じネームサーバを参照していれば、
> > > RTCLinkからネットワーク上のどのコンポーネントでも操作することができます。
> > >
> > > > またConsoleInCompの中でもmanager->createComponent()により
> > > > コンポーネントのインスタンスを生成しているようですが、これ
> > > > とRTCLinkのシステムドローウィンドウのコンポーネントは同一
> > > > インスタンスなのでしょうか、それとも別物でしょうか?
> > >
> > > システムドローウインドウ上の箱は、コンポーネントの
> > > 状態やポートの数を表すためのもので、コンポーネント自体が、
> > > RTCLink上で動いているわけではありません。
> >
> > 了解致しました。どうもありがとうございます。
> >
> > では、RTCLink上でコンポーネントを生成・起動する場合、実際に
> > はその生成・起動要求が上記のConsoleXXCompのプロセスに渡され、
> > そのプロセス下でコンポーネントのインスタンスが生成・起動され
> > るという解釈でよろしいでしょうか?
>
> RTCLink上で、ネームウインドウからドローウインドウにDnDすることによって、
> コンポーネントのインスタンスが生成されることはありません。
>
> ネームツリー上の、例えば ConsoleIn0|rtc という名前は、
> すでに生成されているコンポーネントのインスタンスに対応します。
>
> > その場合、ConsoleXXCompのMyModuleInitの中でcreateComponent
> > により生成しているインスタンスと、RTCLink上で新たにドラッグ
> > &ドロップしたコンポーネントのインスタンスとは別物になるの
> > でしょうか?
>
> ですので同じものです。
>
> お分かりいただけたでしょうか?

どうもありがとうございます。

まだ一点だけ分からないのでご教授頂けますでしょうか?

コンポーネントのプロファイルではMax Instanceで最大インスタンス数を
指定できるかと思いますが、この値を2以上にした場合、RTCLinkからは
同じコンポーネントを2つ以上ドラッグ&ドロップ出来るのでしょうか?

もし出来る場合、ConsoleXXCompでは1つのインスタンスしか生成してい
ないと思いますが、RTCLink上で2つ以上に見えるコンポーネントは、
実は同一のインスタンスを指しているということになるのでしょうか?

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

ダウンロード

最新バージョン : 2.0.1-RELESE

統計

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

Choreonoid

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

OpenHRP3

動力学シミュレータ

OpenRTP

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

産総研RTC集

産総研が提供するRTC集

TORK

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

DAQ-Middleware

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