[openrtm-users 01063] RT System Editorの排出するXMLファイル(RTSファイル?)の仕様について

4 個の投稿 / 0 new
最終投稿
root
オフライン
Last seen: 3日 18時間 前
登録日: 2009-06-23 14:31
[openrtm-users 01063] RT System Editorの排出するXMLファイル(RTSファイル?)の仕様について

OpenRTM-aist メーリングリストの皆様:
お世話になっております.早大の菅です.

さっそく本題です.
RT System Editorと連携できるツールを作っていますが,
System Editorの保存するXMLファイルの仕様が良くないです.

SystemEditorが吐き出すXMLファイルですが,
コネクションのデータ内にRTCのインスタンス名しか
登録できていませんが,この仕様でよいのですか?
フルパスで指定できないと,重複の可能性がありますし,
今作っているツールの用途だと不便になってしまいます.

rts:sourceDataPortにrts:pathUriのアトリビュートを追加できませんか?
(若干ですが名前が誤解を生みそうですね.
rts:componentPathUriのほうがよさそうです.

こまかい話ですがご検討ください.

ではでは

未定義
root
オフライン
Last seen: 3日 18時間 前
登録日: 2009-06-23 14:31
[openrtm-users 01068] RT System Editorの排出するXMLファイル(RTSファイル?)の仕様

早稲田大学 菅様

お世話になっております。
株式会社セックの小田桐です。

ご指摘の問題には私もぶつかりました。
RT System Editorが吐き出すXML(RTS Profile)のポート接続情報には、
対象ポートを持つRTCについて、インスタンス名とRTCの型情報しか
記述されていません。
現在のインスタンス名の命名規則では、別プロセスのRTC同士は
インスタンス名が重複するため、問題が生じることがあります。
これは、以前、[openrtm-users 00833]で私も
指摘させていただいています。

私もツールを作る上で困ったので、とりあえず現状では、
以下のようにRTCのインスタンス名にパスを付与することで
問題を回避しています。
(ホスト名)_(PID)_(通常のRTCのインスタンス名).rtc

C++版以外はまだ見ていないのでわからないのですが、
C++版の1.0.0系では、Manager::createComponent()を
以下のように呼び出せば、既存の命名規則を無視して、
インスタンス名を強制的に上書きできるようになります。
manager->createComponent("ConsoleIn?instance_name=Test");

ただし、RC1ではこの処理に少し問題があり、うまく動作しません。
一応、以下のようにRTObject_impl::initialize()を
オーバライドすればほぼ正しく動くようになります。

RTC::ReturnCode_t Sample::initialize()
throw(CORBA::SystemException)
{
RTC::Properties dummy_prop;
setProperties(dummy_prop); // ★これを呼ぶとインスタンス名が正しく上書きされる
return DataFlowComponentBase::initialize();
}

ご参考になれば幸いです。

以上

On Mon, 28 Dec 2009 20:17:23 +0900
ysuga wrote:

> OpenRTM-aist メーリングリストの皆様:
> お世話になっております.早大の菅です.
>
> さっそく本題です.
> RT System Editorと連携できるツールを作っていますが,
> System Editorの保存するXMLファイルの仕様が良くないです.
>
>
> SystemEditorが吐き出すXMLファイルですが,
> コネクションのデータ内にRTCのインスタンス名しか
> 登録できていませんが,この仕様でよいのですか?
> フルパスで指定できないと,重複の可能性がありますし,
> 今作っているツールの用途だと不便になってしまいます.
>
> rts:sourceDataPortにrts:pathUriのアトリビュートを追加できませんか?
> (若干ですが名前が誤解を生みそうですね.
> rts:componentPathUriのほうがよさそうです.
>
>
> こまかい話ですがご検討ください.
>
> ではでは
>
>

root
オフライン
Last seen: 3日 18時間 前
登録日: 2009-06-23 14:31
[openrtm-users 01073] RT System Editorの排出するXMLファイル(RTSファイル?)の仕様

セック小田桐様,ならびにOpenRTM-aist メーリングリストの皆様:
早大の菅です.お世話になっております.

RTS Profileの仕様についてです.

> これは、以前、[openrtm-users 00833]で私も
> 指摘させていただいています。

やはり既出でしたか…すみません.検索したつもりが…
やっぱり不便ですよね.

レスが付いていないのですが,
RTS Profileの件ですが,デイリービルドの最新版(rtmtools-
r97-0912241200.zip)では改善されているようです.

独学なので言葉でうまく説明できないのですが,
たとえばサービスポートのコネクションに関するノードは,
以下のような構造になっています.

PropertiesのElementを見ればフルパス名が得られます.
今後はsource(target)ServicePortのアトリビュートになればシンプルかな,
と思います.

> (ホスト名)_(PID)_(通常のRTCのインスタンス名).rtc

たしかに名前にPIDを使えば重ならなくなるのですが,
再現性が皆無になってしまうので使いづらい方法だと思いますがどうですか?
僕もNamingContextの部分にPIDを使っていましたが,
システムの自動再構成をするときに不便でした.

> インスタンス名を強制的に上書きできるようになります。
> manager->createComponent("ConsoleIn?instance_name=Test");

この方法は美しいですね.
これ以外にRTObject_impl::setInstanceNameというメソッドがありますね.

こっちはC++版しか試していませんが,設定するとコンポーネントの
プロパティが変更になるだけで,CORBAネームサーバー上のBinding名が
変更になりませんね.

>安藤さん
内部で使っているのでしょうか?publicにする必要がないと思いますが.

これを使えばインスタンス名は簡単に変更が出来てしまうので,
識別子としての価値は皆無ですね.
GUIで表示するときの略称程度に思っています.

CORBAコンポーネントの名前はかなり重要ですが,
(本来はこれがInstanceNameと同じになるはず)
こっちはNamingContextを使えば重ならなく出来そうです.
もはやInstance名は必要無いと思います.

特にバージョン1.0からはManagerがかなり使えるようになっていますよね.
こういうツールを作りました.
RTC-Launcher : http://www.ysuga.net/robot/rtm/practical/rtclauncher.htm
特定のフォルダにあるDLLをすべて読みだして,
RTCを呼び出すことが出来るツールです.
Managerがパワフルなので簡単に作れます.
これならDefaultNumberingPolicyでも問題なく動きますよね?

あとはツール自体をインテリジェントにすれば良いと思います.
現在そういう開発を行っています.

(2010/01/13 17:36), Yasuaki Odagiri wrote:
> 早稲田大学 菅様
>
> お世話になっております。
> 株式会社セックの小田桐です。
>
> ご指摘の問題には私もぶつかりました。
> RT System Editorが吐き出すXML(RTS Profile)のポート接続情報には、
> 対象ポートを持つRTCについて、インスタンス名とRTCの型情報しか
> 記述されていません。
> 現在のインスタンス名の命名規則では、別プロセスのRTC同士は
> インスタンス名が重複するため、問題が生じることがあります。
> これは、以前、[openrtm-users 00833]で私も
> 指摘させていただいています。
>
> 私もツールを作る上で困ったので、とりあえず現状では、
> 以下のようにRTCのインスタンス名にパスを付与することで
> 問題を回避しています。
> (ホスト名)_(PID)_(通常のRTCのインスタンス名).rtc
>
> C++版以外はまだ見ていないのでわからないのですが、
> C++版の1.0.0系では、Manager::createComponent()を
> 以下のように呼び出せば、既存の命名規則を無視して、
> インスタンス名を強制的に上書きできるようになります。
> manager->createComponent("ConsoleIn?instance_name=Test");
>
> ただし、RC1ではこの処理に少し問題があり、うまく動作しません。
> 一応、以下のようにRTObject_impl::initialize()を
> オーバライドすればほぼ正しく動くようになります。
>
> RTC::ReturnCode_t Sample::initialize()
> throw(CORBA::SystemException)
> {
> RTC::Properties dummy_prop;
> setProperties(dummy_prop); // ★これを呼ぶとインスタンス名が正しく上書きされる
> return DataFlowComponentBase::initialize();
> }
>
> ご参考になれば幸いです。
>
> 以上
>
> On Mon, 28 Dec 2009 20:17:23 +0900
> ysuga wrote:
>
>> OpenRTM-aist メーリングリストの皆様:
>> お世話になっております.早大の菅です.
>>
>> さっそく本題です.
>> RT System Editorと連携できるツールを作っていますが,
>> System Editorの保存するXMLファイルの仕様が良くないです.
>>
>>
>> SystemEditorが吐き出すXMLファイルですが,
>> コネクションのデータ内にRTCのインスタンス名しか
>> 登録できていませんが,この仕様でよいのですか?
>> フルパスで指定できないと,重複の可能性がありますし,
>> 今作っているツールの用途だと不便になってしまいます.
>>
>> rts:sourceDataPortにrts:pathUriのアトリビュートを追加できませんか?
>> (若干ですが名前が誤解を生みそうですね.
>> rts:componentPathUriのほうがよさそうです.
>>
>>
>> こまかい話ですがご検討ください.
>>
>> ではでは
>>

root
オフライン
Last seen: 3日 18時間 前
登録日: 2009-06-23 14:31
[openrtm-users 01077] RT System Editorの排出するXMLファイル(RTSファイル?)の仕様

早稲田大学 菅様

お世話になっております。
株式会社セック 小田桐です。

> レスが付いていないのですが,
> RTS Profileの件ですが,デイリービルドの最新版(rtmtools-
> r97-0912241200.zip)では改善されているようです.
そうでしたか。
デイリービルドの方はまだチェックしていませんでした。
情報ありがとうございます。

> > (ホスト名)_(PID)_(通常のRTCのインスタンス名).rtc
>
> たしかに名前にPIDを使えば重ならなくなるのですが,
> 再現性が皆無になってしまうので使いづらい方法だと思いますがどうですか?
> 僕もNamingContextの部分にPIDを使っていましたが,
> システムの自動再構成をするときに不便でした.
おっしゃるとおりだと思います。
私も以前経験がありますが、NamingContextにPIDを使うと、
RTCを起動するたびに毎回異なるNamingContextになるので不便でした。

ただ、今回やりたかったことは、RTS Profile内でRTCのインスタンス名を
一意することでした。そのためにはホスト名+PIDを付与するのが
簡単だったのでこのようにしています。
保存したRTS Profileを使ってシステムを復元する際は、保存されている
RTCのインスタンス名をそのまま使ってRTCを起動します。
つまり、システム復元の際は、RTCのインスタンス名に付与されているPIDと
実際のPIDとは異なります。
ちょっと混乱してしまいそうなので、どうしようか考えているところです。

> これ以外にRTObject_impl::setInstanceNameというメソッドがありますね.
>
> こっちはC++版しか試していませんが,設定するとコンポーネントの
> プロパティが変更になるだけで,CORBAネームサーバー上のBinding名が
> 変更になりませんね.
完全に想像になりますが、Manager::createComponentを呼び出してRTCを
生成した後に、RTObject_impl::setInstanceNameを呼び出しているのでは
ないでしょうか?
#間違っていたらすみません。

ネームサーバに登録される名前は、Manager::createComponent内で
呼び出されるManager::configureComponentで設定されます。
ネームサーバへCORBAオブジェクトを登録する処理も
Manager::createComponent内で行われます。
そのため、Manager::createComponentの後にインスタンス名を変更しても
ネームサーバに登録される名前を変更することはできません。

Manager::createComponentの引数にインスタンス名を渡す方法なら、
ネームサーバに登録される名前も合わせて変更することができます。

なお、RTObject_impl::setInstanceNameは、RTCのインスタンス生成の際に、
FactoryCXX::createが呼び出しているため、publicである必要があります。

> こういうツールを作りました.
> RTC-Launcher : http://www.ysuga.net/robot/rtm/practical/rtclauncher.htm
> 特定のフォルダにあるDLLをすべて読みだして,
> RTCを呼び出すことが出来るツールです.
ちょっと使ってみました。
OpenRTM-aistに付属のrtcdでも似たようなことはできますが、
ロードするdllをrtc.confに書かなければならず、dllが多い場合は
やや手間なので、このツールなら一気にdllをロードできて便利ですね。

以上

On Thu, 14 Jan 2010 14:21:19 +0900
ysuga wrote:

> セック小田桐様,ならびにOpenRTM-aist メーリングリストの皆様:
> 早大の菅です.お世話になっております.
>
>
> RTS Profileの仕様についてです.
>
> > これは、以前、[openrtm-users 00833]で私も
> > 指摘させていただいています。
>
> やはり既出でしたか…すみません.検索したつもりが…
> やっぱり不便ですよね.
>
> レスが付いていないのですが,
> RTS Profileの件ですが,デイリービルドの最新版(rtmtools-
> r97-0912241200.zip)では改善されているようです.
>
>
>
> 独学なので言葉でうまく説明できないのですが,
> たとえばサービスポートのコネクションに関するノードは,
> 以下のような構造になっています.
>
>
> rtsExt:name="COMPONENT_PATH_ID"/>
>
>
> rtsExt:name="COMPONENT_PATH_ID"/>
>
>
>
>
> PropertiesのElementを見ればフルパス名が得られます.
> 今後はsource(target)ServicePortのアトリビュートになればシンプルかな,
> と思います.
>
>
>
> > (ホスト名)_(PID)_(通常のRTCのインスタンス名).rtc
>
> たしかに名前にPIDを使えば重ならなくなるのですが,
> 再現性が皆無になってしまうので使いづらい方法だと思いますがどうですか?
> 僕もNamingContextの部分にPIDを使っていましたが,
> システムの自動再構成をするときに不便でした.
>
>
> > インスタンス名を強制的に上書きできるようになります。
> > manager->createComponent("ConsoleIn?instance_name=Test");
>
> この方法は美しいですね.
> これ以外にRTObject_impl::setInstanceNameというメソッドがありますね.
>
> こっちはC++版しか試していませんが,設定するとコンポーネントの
> プロパティが変更になるだけで,CORBAネームサーバー上のBinding名が
> 変更になりませんね.
>
> >安藤さん
> 内部で使っているのでしょうか?publicにする必要がないと思いますが.
>
> これを使えばインスタンス名は簡単に変更が出来てしまうので,
> 識別子としての価値は皆無ですね.
> GUIで表示するときの略称程度に思っています.
>
>
> CORBAコンポーネントの名前はかなり重要ですが,
> (本来はこれがInstanceNameと同じになるはず)
> こっちはNamingContextを使えば重ならなく出来そうです.
> もはやInstance名は必要無いと思います.
>
>
> 特にバージョン1.0からはManagerがかなり使えるようになっていますよね.
> こういうツールを作りました.
> RTC-Launcher : http://www.ysuga.net/robot/rtm/practical/rtclauncher.htm
> 特定のフォルダにあるDLLをすべて読みだして,
> RTCを呼び出すことが出来るツールです.
> Managerがパワフルなので簡単に作れます.
> これならDefaultNumberingPolicyでも問題なく動きますよね?
>
>
>
> あとはツール自体をインテリジェントにすれば良いと思います.
> 現在そういう開発を行っています.
>
>
> (2010/01/13 17:36), Yasuaki Odagiri wrote:
> > 早稲田大学 菅様
> >
> > お世話になっております。
> > 株式会社セックの小田桐です。
> >
> > ご指摘の問題には私もぶつかりました。
> > RT System Editorが吐き出すXML(RTS Profile)のポート接続情報には、
> > 対象ポートを持つRTCについて、インスタンス名とRTCの型情報しか
> > 記述されていません。
> > 現在のインスタンス名の命名規則では、別プロセスのRTC同士は
> > インスタンス名が重複するため、問題が生じることがあります。
> > これは、以前、[openrtm-users 00833]で私も
> > 指摘させていただいています。
> >
> > 私もツールを作る上で困ったので、とりあえず現状では、
> > 以下のようにRTCのインスタンス名にパスを付与することで
> > 問題を回避しています。
> > (ホスト名)_(PID)_(通常のRTCのインスタンス名).rtc
> >
> > C++版以外はまだ見ていないのでわからないのですが、
> > C++版の1.0.0系では、Manager::createComponent()を
> > 以下のように呼び出せば、既存の命名規則を無視して、
> > インスタンス名を強制的に上書きできるようになります。
> > manager->createComponent("ConsoleIn?instance_name=Test");
> >
> > ただし、RC1ではこの処理に少し問題があり、うまく動作しません。
> > 一応、以下のようにRTObject_impl::initialize()を
> > オーバライドすればほぼ正しく動くようになります。
> >
> > RTC::ReturnCode_t Sample::initialize()
> > throw(CORBA::SystemException)
> > {
> > RTC::Properties dummy_prop;
> > setProperties(dummy_prop); // ★これを呼ぶとインスタンス名が正しく上書きされる
> > return DataFlowComponentBase::initialize();
> > }
> >
> > ご参考になれば幸いです。
> >
> > 以上
> >
> > On Mon, 28 Dec 2009 20:17:23 +0900
> > ysuga wrote:
> >
> >> OpenRTM-aist メーリングリストの皆様:
> >> お世話になっております.早大の菅です.
> >>
> >> さっそく本題です.
> >> RT System Editorと連携できるツールを作っていますが,
> >> System Editorの保存するXMLファイルの仕様が良くないです.
> >>
> >>
> >> SystemEditorが吐き出すXMLファイルですが,
> >> コネクションのデータ内にRTCのインスタンス名しか
> >> 登録できていませんが,この仕様でよいのですか?
> >> フルパスで指定できないと,重複の可能性がありますし,
> >> 今作っているツールの用途だと不便になってしまいます.
> >>
> >> rts:sourceDataPortにrts:pathUriのアトリビュートを追加できませんか?
> >> (若干ですが名前が誤解を生みそうですね.
> >> rts:componentPathUriのほうがよさそうです.
> >>
> >>
> >> こまかい話ですがご検討ください.
> >>
> >> ではでは
> >>

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

ダウンロード

最新バージョン : 2.0.1-RELESE

統計

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

Choreonoid

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

OpenHRP3

動力学シミュレータ

OpenRTP

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

産総研RTC集

産総研が提供するRTC集

TORK

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

DAQ-Middleware

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