[openrtm-users 00927] C++/PythonのSystemEditor上での現れ方について

8 posts / 0 new
Last post
root
Offline
Last seen: 1 day 11 hours ago
Joined: 2009-06-23 14:31
[openrtm-users 00927] C++/PythonのSystemEditor上での現れ方について

鳥井@HRI-JPです。

Python版も1.0.0-RC1-p1が出たということですので、今回初めて
Windows 7上にC++,Python両版(1.0.0-RC1)をインストールしてみました。
そこで、質問がひとつございます。

C++ のConsoleIn と Pythonの ConsoleIn を同時に起動しておくと、
RTSystemEditor上では C++版のほうは ホスト名|host_cxtという
コンテキストノード(というのでしょうか?)の下にコンポーネントが現れますが、
Python版のほうはルート直下に現れるようです。これはこう言う仕様という
ことでしょうか? それともPython版もコンテキストノードを指定して
その直下に置くことは可能でしょうか? ちなみにPython版は1.0.0になって
初めての導入となります。

あと、余談ですが、私の使っているWindows 7 ではVMWare Workstationがインス
トール
されています。当初このことを忘れて、rtm-naming.batを起動したため、
Eclipse上のRTSystemEditor上でサーバと接続できず、慌てました。
そこで、VWMwareのことを思い出し、環境変数 OMNIORB_USEHOSTNAMEを
明示的に設定して再度サーバを立ち上げてみたのですが、やはり接続できず、
rtm-naming.batを覗いてみたところ、OMNIORB_USEHOSTNAMEが
直接localhostに設定されていることを知りました。ここは port の処理同様、
存在すればその値を使うようにした方が良いかと存じます。本当に細かいことです

既出でしたら申し訳ありません。

以上、よろしくお願いいたします。

Undefined
root
Offline
Last seen: 1 day 11 hours ago
Joined: 2009-06-23 14:31
[openrtm-users 00928] C++/PythonのSystemEditor上での現れ方について

株式会社ホンダ・リサーチ・インスティチュート・ジャパン
鳥井 様

お世話になっております。
産総研 栗原です。

SystemEditor上でのRTCの表示に関してですが、rtc.confの記述方法が異なる
ことによるものです。

C++版の場合は、ConsoleInコンポーネントと同じフォルダに存在します
rtc.confファイルの"naming.formats"が"%h.host_cxt/%n.rtc"となっている
のに対し、Python版では"naming.formats"が"%n.rtc"となっております。

もし、ホストコンテキスト配下にRTCを表示したい場合は、Python版の
ConsoleInコンポーネントと同じフォルダにあるrtc.confの"naming.formats"
をC++版同様に"%h.host_cxt/%n.rtc"のように書き換えて頂けますでしょうか。

なお、"naming.formats"に関しましては、C:\Program Files\OpenRTM-aist\1.0\etc
のrtc.conf.sampleに記述してありますので、そちらを参照願います。

お手数をお掛け致しまして申し訳ございません。
宜しくお願い致します。

On Thu, 03 Sep 2009 14:50:15 +0900
"TORII, Toyotaka" wrote:

> 鳥井@HRI-JPです。
>
> Python版も1.0.0-RC1-p1が出たということですので、今回初めて
> Windows 7上にC++,Python両版(1.0.0-RC1)をインストールしてみました。
> そこで、質問がひとつございます。
>
> C++ のConsoleIn と Pythonの ConsoleIn を同時に起動しておくと、
> RTSystemEditor上では C++版のほうは ホスト名|host_cxtという
> コンテキストノード(というのでしょうか?)の下にコンポーネントが現れますが、
> Python版のほうはルート直下に現れるようです。これはこう言う仕様という
> ことでしょうか? それともPython版もコンテキストノードを指定して
> その直下に置くことは可能でしょうか? ちなみにPython版は1.0.0になって
> 初めての導入となります。
>
> あと、余談ですが、私の使っているWindows 7 ではVMWare Workstationがインス
> トール
> されています。当初このことを忘れて、rtm-naming.batを起動したため、
> Eclipse上のRTSystemEditor上でサーバと接続できず、慌てました。
> そこで、VWMwareのことを思い出し、環境変数 OMNIORB_USEHOSTNAMEを
> 明示的に設定して再度サーバを立ち上げてみたのですが、やはり接続できず、
> rtm-naming.batを覗いてみたところ、OMNIORB_USEHOSTNAMEが
> 直接localhostに設定されていることを知りました。ここは port の処理同様、
> 存在すればその値を使うようにした方が良いかと存じます。本当に細かいことです
> が
> 既出でしたら申し訳ありません。
>
> 以上、よろしくお願いいたします。

root
Offline
Last seen: 1 day 11 hours ago
Joined: 2009-06-23 14:31
[openrtm-users 00930] C++/PythonのSystemEditor上での現れ方について

鳥井@HRI-JPです。

北原様、ありがとうございます。

At 03 Sep 2009 15:17:13 +0900 kurihara shinji wrote:

> SystemEditor上でのRTCの表示に関してですが、rtc.confの記述方法が異なる
> ことによるものです。
>
> C++版の場合は、ConsoleInコンポーネントと同じフォルダに存在します
> rtc.confファイルの"naming.formats"が"%h.host_cxt/%n.rtc"となっている
> のに対し、Python版では"naming.formats"が"%n.rtc"となっております。
>
> もし、ホストコンテキスト配下にRTCを表示したい場合は、Python版の
> ConsoleInコンポーネントと同じフォルダにあるrtc.confの"naming.formats"
> をC++版同様に"%h.host_cxt/%n.rtc"のように書き換えて頂けますでしょうか。

そうでしたか、rtc.confをよく読めば推測できることでした。
お時間をお掛けして申し訳ありませんでした。ついでにといっては
なんですが、ConsoleInComp.exe と ConsoleIn.py では、
RTSystemEditorに現れたときのOutpPort/Subscription Typeに現れる
タイプの順番が違うようです。、
この順番をC++版コンポーネントとあわせることは可能でしょうか?
些細な事、というか気分の問題なので、時間のあるときにでもご教示ください。

なお、「余談」の方は、投稿後にこちらの記述を見つけました一年前の話だったの
ですね。
お騒がせして申し訳ありませんでした。

http://pw1.atcms.jp/kencyo/index.php?VISTA%A4%C7%A4%CE%CC%E4%C2%EA%C5%C0

root
Offline
Last seen: 1 day 11 hours ago
Joined: 2009-06-23 14:31
[openrtm-users 00929] C++/PythonのSystemEditor上での現れ方について

皆様、

大橋@九工大と申します。

> あと、余談ですが、私の使っているWindows 7 ではVMWare Workstationがインス
> トール
> されています。当初このことを忘れて、rtm-naming.batを起動したため、
> Eclipse上のRTSystemEditor上でサーバと接続できず、慌てました。
> そこで、VWMwareのことを思い出し、環境変数 OMNIORB_USEHOSTNAMEを
> 明示的に設定して再度サーバを立ち上げてみたのですが、やはり接続できず、
> rtm-naming.batを覗いてみたところ、OMNIORB_USEHOSTNAMEが
> 直接localhostに設定されていることを知りました。ここは port の処理同様、
> 存在すればその値を使うようにした方が良いかと存じます。本当に細かいことです
> が
> 既出でしたら申し訳ありません。

こちらに関連した内容ですが、OMNIORB_USEHOSTNAME にはいつから
かIPアドレスではつながらず FQDN で書いてもドメインが無視されて
しまうように思います。また、このことからホスト名から IPアドレス
が解決できないとアクセスできなくてリモートから接続できないこと
になっているようです。DNSがない環境(ロボット内部など)の場合、
/etc/hosts や %SYSTEMROOT%\system32\drivers\etc\hosts
に直接書いておく必要があるようです。
# これに気づかなくてしばらくはまってしまいました。

ちなみに、Java版は 0.4.2 までなのでそこでしか確認していません。

root
Offline
Last seen: 1 day 11 hours ago
Joined: 2009-06-23 14:31
[openrtm-users 00931] C++/PythonのSystemEditor上での現れ方について

鳥井@HRI-JPです。

先ほど、00930のメールで、「栗原様」とすべきところを
「北原様」と間違えて返信してしまいました。申し訳ありません、
お詫びして訂正いたします。

#何故北原という名前が出てきたのか不明です。寝不足でしょうか...

さて、
大橋様

At 03 Sep 2009 15:34:23 +0900 Takeshi OHASHI wrote:
> こちらに関連した内容ですが、OMNIORB_USEHOSTNAME にはいつから
> かIPアドレスではつながらず FQDN で書いてもドメインが無視されて
> しまうように思います。また、このことからホスト名から IPアドレス
> が解決できないとアクセスできなくてリモートから接続できないこと
> になっているようです。DNSがない環境(ロボット内部など)の場合、
> /etc/hosts や %SYSTEMROOT%\system32\drivers\etc\hosts
> に直接書いておく必要があるようです。
> # これに気づかなくてしばらくはまってしまいました。

こちら(VistaからアップデートしたWindows 7)では、
直IPを指定することで接続できています。また、
IPv6関係をすべて無効することで、"localhost" で繋がるようになりました。
# hosts の "::1 localhost"も削除しました。

あまりよい解決策ではなさそうですが、一応ご報告まで。

root
Offline
Last seen: 1 day 11 hours ago
Joined: 2009-06-23 14:31
[openrtm-users 00932] C++/PythonのSystemEditor上での現れ方について

鳥井 様

産総研 栗原です。

> RTSystemEditorに現れたときのOutpPort/Subscription Typeに現れる
> タイプの順番が違うようです。、
> この順番をC++版コンポーネントとあわせることは可能でしょうか?
> 些細な事、というか気分の問題なので、時間のあるときにでもご教示ください。
こちらに関しましては、Python版では、Subscriptionタイプを辞書で管理して
おりまして、辞書からキーを取得する際にご指摘のような順序になっているよう
です。

具体的には、Subscriptionタイプをflush,new,periodicの順で登録しているので
すが、辞書から取得するさいに"new,periodic,flush"のようになってしまいます。

下記のようにする事で確認できます。

$ python
Python 2.5.2 (r252:60911, Oct 5 2008, 19:24:49)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>> m={"flush":0,"new":1,"periodic":2}
>>> m
{'new': 1, 'periodic': 2, 'flush': 0}
>>> m.keys()
['new', 'periodic', 'flush']
>>>

一応、キーのリストをlist.sort()を用いてソートする事で"flush,new,periodic"
にする事は可能です。
C:\Python26\Lib\site-packages\OpenRTM_aistのGlobalFactory.pyのgetIdentifiers(self)
関数のreturn文の前にidllist.sort()を追加する事で"flush,new,periodic"の順になる
事は確認致しました。

他に何か良い方法をご存知の方がいらっしゃいましたらご教授頂けますと幸いです。

以上、宜しくお願い致します。

> さて、
> 大橋様
>
> At 03 Sep 2009 15:34:23 +0900 Takeshi OHASHI wrote:
> > こちらに関連した内容ですが、OMNIORB_USEHOSTNAME にはいつから
> > かIPアドレスではつながらず FQDN で書いてもドメインが無視されて
> > しまうように思います。また、このことからホスト名から IPアドレス
> > が解決できないとアクセスできなくてリモートから接続できないこと
> > になっているようです。DNSがない環境(ロボット内部など)の場合、
> > /etc/hosts や %SYSTEMROOT%\system32\drivers\etc\hosts
> > に直接書いておく必要があるようです。
> > # これに気づかなくてしばらくはまってしまいました。
>
> こちら(VistaからアップデートしたWindows 7)では、
> 直IPを指定することで接続できています。また、
> IPv6関係をすべて無効することで、"localhost" で繋がるようになりました。
> # hosts の "::1 localhost"も削除しました。
>
> あまりよい解決策ではなさそうですが、一応ご報告まで。
>
>
>

root
Offline
Last seen: 1 day 11 hours ago
Joined: 2009-06-23 14:31
[openrtm-users 00933] C++/PythonのSystemEditor上での現れ方について

鳥井@HRI-JPです。

栗原様、先ほどは失礼足しました。
また、大変詳細な解説をありがとうございました。

Python3.1では順序つき辞書がサポートされるようですが、
やはり需要があるのでしょうね。

些細なことにこだわらず、しばらくOpenRTMを使ってみようと思います。
今後ともよろしくお願いいたします。

At 03 Sep 2009 17:21:34 +0900 kurihara shinji wrote:
> 鳥井 様
>
> 産総研 栗原です。
>
> > RTSystemEditorに現れたときのOutpPort/Subscription Typeに現れる
> > タイプの順番が違うようです。、
> > この順番をC++版コンポーネントとあわせることは可能でしょうか?
> > 些細な事、というか気分の問題なので、時間のあるときにでもご教示ください。

> こちらに関しましては、Python版では、Subscriptionタイプを辞書で管理して
> おりまして、辞書からキーを取得する際にご指摘のような順序になっているよう
> です。
>
> 具体的には、Subscriptionタイプをflush,new,periodicの順で登録しているので
> すが、辞書から取得するさいに"new,periodic,flush"のようになってしまいます。

>
> 下記のようにする事で確認できます。
>
> $ python
> Python 2.5.2 (r252:60911, Oct 5 2008, 19:24:49)
> [GCC 4.3.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>>
> >>> m={"flush":0,"new":1,"periodic":2}
> >>> m
> {'new': 1, 'periodic': 2, 'flush': 0}
> >>> m.keys()
> ['new', 'periodic', 'flush']
> >>>
>
> 一応、キーのリストをlist.sort()を用いてソートする事で
"flush,new,periodic"
> にする事は可能です。
> C:\Python26\Lib\site-packages\OpenRTM_aistのGlobalFactory.pyの
getIdentifiers(self)
> 関数のreturn文の前にidllist.sort()を追加する事で"flush,new,periodic"の順
になる
> 事は確認致しました。
>
> 他に何か良い方法をご存知の方がいらっしゃいましたらご教授頂けますと幸いで
す。
>
>
> 以上、宜しくお願い致します。

root
Offline
Last seen: 1 day 11 hours ago
Joined: 2009-06-23 14:31
[openrtm-users 00934] C++/PythonのSystemEditor上での現れ方について

皆様

安藤です

接続プロパティに関して、たとえば subscription type に関していえば、
常にどのポートも flush, new, periodic をサポートするとは限らず、
一部かけているポート (flushしかサポートしないとか)や、これら以外の
subscription type をサポートするポート(たとえば、外部トリガにより
送信タイミングを与えるなど)など、いろいろなケースが考えられます。

RTSystemEditorでは、2つ(またはそれ以上)のポートを接続する際に、
それらのポートがサポートするsubscription type などのプロパティの
ANDをとって、ダイアログに表示しています。

したがって、これらの順序に関してはRTSystemEditorで面倒を
見てあげるのが正しいように思います。

順序は本来関係ないとはいえ、接続ごとに順序が異なるのは
操作時にストレスであることは、私もこの間この件で経験しましたので
よく理解できます。次のバージョンではその辺改善したいと思います。

以上、よろしくお願いいたします。

2009/09/03 17:47 に TORII, Toyotaka さんは書きました:
> 鳥井@HRI-JPです。
>
> 栗原様、先ほどは失礼足しました。
> また、大変詳細な解説をありがとうございました。
>
> Python3.1では順序つき辞書がサポートされるようですが、
> やはり需要があるのでしょうね。
>
> 些細なことにこだわらず、しばらくOpenRTMを使ってみようと思います。
> 今後ともよろしくお願いいたします。
>
> At 03 Sep 2009 17:21:34 +0900 kurihara shinji wrote:
>> 鳥井 様
>>
>> 産総研 栗原です。
>>
>> > RTSystemEditorに現れたときのOutpPort/Subscription Typeに現れる
>> > タイプの順番が違うようです。、
>> > この順番をC++版コンポーネントとあわせることは可能でしょうか?
>> > 些細な事、というか気分の問題なので、時間のあるときにでもご教示ください。
>
>> こちらに関しましては、Python版では、Subscriptionタイプを辞書で管理して
>> おりまして、辞書からキーを取得する際にご指摘のような順序になっているよう
>> です。
>>
>> 具体的には、Subscriptionタイプをflush,new,periodicの順で登録しているので
>> すが、辞書から取得するさいに"new,periodic,flush"のようになってしまいます。
>
>>
>> 下記のようにする事で確認できます。
>>
>> $ python
>> Python 2.5.2 (r252:60911, Oct 5 2008, 19:24:49)
>> [GCC 4.3.2] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>>
>> >>> m={"flush":0,"new":1,"periodic":2}
>> >>> m
>> {'new': 1, 'periodic': 2, 'flush': 0}
>> >>> m.keys()
>> ['new', 'periodic', 'flush']
>> >>>
>>
>> 一応、キーのリストをlist.sort()を用いてソートする事で
> "flush,new,periodic"
>> にする事は可能です。
>> C:\Python26\Lib\site-packages\OpenRTM_aistのGlobalFactory.pyの
> getIdentifiers(self)
>> 関数のreturn文の前にidllist.sort()を追加する事で"flush,new,periodic"の順
> になる
>> 事は確認致しました。
>>
>> 他に何か良い方法をご存知の方がいらっしゃいましたらご教授頂けますと幸いで
> す。
>>
>>
>> 以上、宜しくお願い致します。
>
>
>

Log in or register to post comments

Download

latest Releases : 2.0.0-RELESE

2.0.0-RELESE Download page

Number of Projects

Choreonoid

Motion editor/Dynamics simulator

OpenHRP3

Dynamics simulator

OpenRTP

Integrated Development Platform

AIST RTC collection

RT-Components collection by AIST

TORK

Tokyo Opensource Robotics Association

DAQ-Middleware

Middleware for DAQ (Data Aquisition) by KEK