[openrtm-users 02314] リアルタイム処理を行うRTCのDataportへの接続で起こる問題の調査方法

8 個の投稿 / 0 new
最終投稿
Manabu Saito
オフライン
Last seen: なし 前
登録日: 2011-11-14 17:20
[openrtm-users 02314] リアルタイム処理を行うRTCのDataportへの接続で起こる問題の調査方法

OpenRTM-usersの皆様

はじめまして、東京大学の斉藤と申します。

OpenHRP3を利用したシミュレーション環境内ロボットと通信していた自作RTCを
実際のロボットで動かした際に、ロボット側RTCとの通信が出来なくなるということが起こりました。
この現象について、subscription_typeがデフォルトのflushのままだと
リアルタイム側に問題が起こるということを詳しい方から聞き、newにして接続することで解決しました.
(データの送信を別スレッドで行う必要があるようです)

RTSystemEditorをつかって手動でつなげる場合は,これでうまくいくのですが,
rtshellでsubscription_typeをnewにしたデータポートの接続をすると、
どうやらRTCがクラッシュしているようなのですが、
どのように問題を調査すればいいかの指針を皆様に伺いたく存じます。

抜粋すると以下のようなスクリプトになっており、これで接続ができていないようです。
(svn co https://rtm-ros-robotics.googlecode.com/svn/trunk/rtmros_common/openrtm/scripts
の rtmlaunch.py)

props = {'dataport.subscription_type': 'new'}
options = optparse.Values({'verbose': False, 'id': '', 'name':None,
'properties': props})
rtcon.connect_ports(source_path, source_full_path,
dest_path,dest_full_path, options, tree=None)

一方jythonのインタフェースを利用した接続スクリプトを書くと動きました。
(svn co https://rtm-ros-robotics.googlecode.com/svn/trunk/rtmros_commonの
hrpsys/bin/hrpsyspyを実行し、hrpsys_ros_bridge/scripts のhrpsys-bridge-connect.pyをロード)

connectPorts(findRTC(node1).port(port1),findRTC(node2).port(port2),
subscription='new')

Dataportの接続について知識不足なこともあり、リアルタイムの問題ともrtshellの問題とも切り分けられておりません。
なにか似たような現象などをご存知の方は、お教えいただきたく思います。

よろしくお願いいたします。

未定義
root
オフライン
Last seen: 6日 18時間 前
登録日: 2009-06-23 14:31
[openrtm-users 02329] リアルタイム処理を行うRTCのDataportへの接続で起こる問題の調査方法

産総研 安藤です
ちなみに、落ちるRTCはInPort側のRTCですか?OutPort側のRTCですか?また、RTCはどこで落ちているかお分かりになりますか?

2011年11月14日17:14 Manabu Saito :
> OpenRTM-usersの皆様
>
> はじめまして、東京大学の斉藤と申します。
>
> OpenHRP3を利用したシミュレーション環境内ロボットと通信していた自作RTCを
> 実際のロボットで動かした際に、ロボット側RTCとの通信が出来なくなるということが起こりました。
> この現象について、subscription_typeがデフォルトのflushのままだと
> リアルタイム側に問題が起こるということを詳しい方から聞き、newにして接続することで解決しました.
> (データの送信を別スレッドで行う必要があるようです)
>
> RTSystemEditorをつかって手動でつなげる場合は,これでうまくいくのですが,
> rtshellでsubscription_typeをnewにしたデータポートの接続をすると、
> どうやらRTCがクラッシュしているようなのですが、
> どのように問題を調査すればいいかの指針を皆様に伺いたく存じます。
>
> 抜粋すると以下のようなスクリプトになっており、これで接続ができていないようです。
> (svn co https://rtm-ros-robotics.googlecode.com/svn/trunk/rtmros_common/openrtm/scripts
> の rtmlaunch.py)
>
> props = {'dataport.subscription_type': 'new'}
> options = optparse.Values({'verbose': False, 'id': '', 'name':None,
> 'properties': props})
> rtcon.connect_ports(source_path, source_full_path,
> dest_path,dest_full_path, options, tree=None)
>
> 一方jythonのインタフェースを利用した接続スクリプトを書くと動きました。
> (svn co https://rtm-ros-robotics.googlecode.com/svn/trunk/rtmros_commonの
> hrpsys/bin/hrpsyspyを実行し、hrpsys_ros_bridge/scripts のhrpsys-bridge-connect.pyをロード)
>
> connectPorts(findRTC(node1).port(port1),findRTC(node2).port(port2),
> subscription='new')
>
> Dataportの接続について知識不足なこともあり、リアルタイムの問題ともrtshellの問題とも切り分けられておりません。
> なにか似たような現象などをご存知の方は、お教えいただきたく思います。
>
> よろしくお願いいたします。
>
> --
> 斉藤 学 (Saito, Manabu)
> 東京大学 情報理工学系研究科 創造情報学専攻 修士2年
> mobile:090-3768-2158 e-mail:saito@jsk.t.u-tokyo.ac.jp
> 〒113-8656 東京都文京区本郷7-3-1
> 工学部二号館73A4(稲葉研究室) tel:03-5841-8360
> _______________________________________________
> openrtm-users mailing list
> openrtm-users@openrtm.org
> http://www.openrtm.org/mailman/listinfo/openrtm-users
>

Manabu Saito
オフライン
Last seen: なし 前
登録日: 2011-11-14 17:20
[openrtm-users 02331] リアルタイム処理を行うRTCのDataportへの接続で起こる問題の調査方法

東京大学の斉藤です。
ご返信いただきありがとうございます。

落ちるRTCは送信側/OutPort側のRTCですが、どこで落ちているかはわかっておりません。
それを調べるのが一番にすべきことでした...

ただ、受信側には接続できていれば得られる出力が一度もないまま、
SystemEditorでは灰色表示のゾンビコンポーネントとなっておりました。

2011年11月17日0:30 Ando Noriaki :
> 産総研 安藤です
> ちなみに、落ちるRTCはInPort側のRTCですか?OutPort側のRTCですか?また、RTCはどこで落ちているかお分かりになりますか?
>
>
> 2011年11月14日17:14 Manabu Saito :
>> OpenRTM-usersの皆様
>>
>> はじめまして、東京大学の斉藤と申します。
>>
>> OpenHRP3を利用したシミュレーション環境内ロボットと通信していた自作RTCを
>> 実際のロボットで動かした際に、ロボット側RTCとの通信が出来なくなるということが起こりました。
>> この現象について、subscription_typeがデフォルトのflushのままだと
>> リアルタイム側に問題が起こるということを詳しい方から聞き、newにして接続することで解決しました.
>> (データの送信を別スレッドで行う必要があるようです)
>>
>> RTSystemEditorをつかって手動でつなげる場合は,これでうまくいくのですが,
>> rtshellでsubscription_typeをnewにしたデータポートの接続をすると、
>> どうやらRTCがクラッシュしているようなのですが、
>> どのように問題を調査すればいいかの指針を皆様に伺いたく存じます。
>>
>> 抜粋すると以下のようなスクリプトになっており、これで接続ができていないようです。
>> (svn co https://rtm-ros-robotics.googlecode.com/svn/trunk/rtmros_common/openrtm/scripts
>> の rtmlaunch.py)
>>
>> props = {'dataport.subscription_type': 'new'}
>> options = optparse.Values({'verbose': False, 'id': '', 'name':None,
>> 'properties': props})
>> rtcon.connect_ports(source_path, source_full_path,
>> dest_path,dest_full_path, options, tree=None)
>>
>> 一方jythonのインタフェースを利用した接続スクリプトを書くと動きました。
>> (svn co https://rtm-ros-robotics.googlecode.com/svn/trunk/rtmros_commonの
>> hrpsys/bin/hrpsyspyを実行し、hrpsys_ros_bridge/scripts のhrpsys-bridge-connect.pyをロード)
>>
>> connectPorts(findRTC(node1).port(port1),findRTC(node2).port(port2),
>> subscription='new')
>>
>> Dataportの接続について知識不足なこともあり、リアルタイムの問題ともrtshellの問題とも切り分けられておりません。
>> なにか似たような現象などをご存知の方は、お教えいただきたく思います。
>>
>> よろしくお願いいたします。
>>
>> --
>> 斉藤 学 (Saito, Manabu)
>> 東京大学 情報理工学系研究科 創造情報学専攻 修士2年
>> mobile:090-3768-2158 e-mail:saito@jsk.t.u-tokyo.ac.jp
>> 〒113-8656 東京都文京区本郷7-3-1
>> 工学部二号館73A4(稲葉研究室) tel:03-5841-8360
>> _______________________________________________
>> openrtm-users mailing list
>> openrtm-users@openrtm.org
>> http://www.openrtm.org/mailman/listinfo/openrtm-users
>>
>
>
>
> --
> 安藤慶昭@独立行政法人産業技術総合研究所 知能システム研究部門
> 統合知能研究グループ 主任研究員, 博士(工学)
> 〒305-8568 つくば市梅園1-1-1 中央第2
> e-mail: n-ando@aist.go.jp, web: http://staff.aist.go.jp/n-ando
> OpenRTM-aist: http://www.openrtm.org
>
> Noriaki Ando, Ph.D.
> Senior Research Scientist, RT-Synthesis R.G., ISRI, AIST
> AIST Tsukuba Central 2, Tsukuba, Ibaraki 305-8568 JAPAN
> e-mail: n-ando@aist.go.jp, web: http://staff.aist.go.jp/n-ando
> OpenRTM-aist: http://www.openrtm.org
> _______________________________________________
> openrtm-users mailing list
> openrtm-users@openrtm.org
> http://www.openrtm.org/mailman/listinfo/openrtm-users
>

gbiggs
オフライン
Last seen: 6年 9ヶ月 前
登録日: 2010-08-02 07:51
[openrtm-users 02336] リアルタイム処理を行うRTCのDataportへの接続で起こる問題の調査方法

斉藤様

ジェフです。

subscription_typeの問題について、こちらでrtshellを手動で
subscription_typeをnewにできると確認しました。rtmlaunchを使った後、rtcat
-ll でコネクタのsubscription_typeは何の値かの確認をお願いします。後、手
動でrtconで接続したらどの値になるかの確認をお願い致します。例えば:

$ rtcon ConsoleIn0.rtc:out ConsoleOut0.rtc:in -p
dataport.subscription_type=new

$ rtcat -ll ConsoleIn0.rtc:out
-DataOutPort: out
dataport.data_type IDL:RTC/TimedLong:1.0
dataport.dataflow_type push,pull
dataport.interface_type corba_cdr
dataport.subscription_type flush,new,periodic
port.port_type DataOutPort
-Connected to /localhost/kenroke.host_cxt/ConsoleOut0.rtc:in
Name outin
ID 1936167d-3ab4-4c73-a876-ab2a38c46d65
dataport.subscription_type new
dataport.interface_type corba_cdr
dataport.dataflow_type push
dataport.data_type IDL:RTC/TimedLong:1.0
dataport.serializer.cdr.endian little,big

クラッシュの問題は、LinuxやOSXの場合ならgdbでコンポーネントを実行して、
クラッシュしたら「bt」というコマンドでbacktraceを取ってみてください。
backtraceでどこにクラッシュしたかが見えます。

よろしくお願いいたします。

On 17/11/11 01:37, Manabu Saito wrote:
> 東京大学の斉藤です。
> ご返信いただきありがとうございます。
>
> 落ちるRTCは送信側/OutPort側のRTCですが、どこで落ちているかはわかっておりません。
> それを調べるのが一番にすべきことでした...
>
> ただ、受信側には接続できていれば得られる出力が一度もないまま、
> SystemEditorでは灰色表示のゾンビコンポーネントとなっておりました。
>
> 2011年11月17日0:30 Ando Noriaki:
>> 産総研 安藤です
>> ちなみに、落ちるRTCはInPort側のRTCですか?OutPort側のRTCですか?また、RTCはどこで落ちているかお分かりになりますか?
>>
>>
>> 2011年11月14日17:14 Manabu Saito:
>>> OpenRTM-usersの皆様
>>>
>>> はじめまして、東京大学の斉藤と申します。
>>>
>>> OpenHRP3を利用したシミュレーション環境内ロボットと通信していた自作RTCを
>>> 実際のロボットで動かした際に、ロボット側RTCとの通信が出来なくなるということが起こりました。
>>> この現象について、subscription_typeがデフォルトのflushのままだと
>>> リアルタイム側に問題が起こるということを詳しい方から聞き、newにして接続することで解決しました.
>>> (データの送信を別スレッドで行う必要があるようです)
>>>
>>> RTSystemEditorをつかって手動でつなげる場合は,これでうまくいくのですが,
>>> rtshellでsubscription_typeをnewにしたデータポートの接続をすると、
>>> どうやらRTCがクラッシュしているようなのですが、
>>> どのように問題を調査すればいいかの指針を皆様に伺いたく存じます。
>>>
>>> 抜粋すると以下のようなスクリプトになっており、これで接続ができていないようです。
>>> (svn co https://rtm-ros-robotics.googlecode.com/svn/trunk/rtmros_common/openrtm/scripts
>>> の rtmlaunch.py)
>>>
>>> props = {'dataport.subscription_type': 'new'}
>>> options = optparse.Values({'verbose': False, 'id': '', 'name':None,
>>> 'properties': props})
>>> rtcon.connect_ports(source_path, source_full_path,
>>> dest_path,dest_full_path, options, tree=None)
>>>
>>> 一方jythonのインタフェースを利用した接続スクリプトを書くと動きました。
>>> (svn co https://rtm-ros-robotics.googlecode.com/svn/trunk/rtmros_commonの
>>> hrpsys/bin/hrpsyspyを実行し、hrpsys_ros_bridge/scripts のhrpsys-bridge-connect.pyをロード)
>>>
>>> connectPorts(findRTC(node1).port(port1),findRTC(node2).port(port2),
>>> subscription='new')
>>>
>>> Dataportの接続について知識不足なこともあり、リアルタイムの問題ともrtshellの問題とも切り分けられておりません。
>>> なにか似たような現象などをご存知の方は、お教えいただきたく思います。
>>>
>>> よろしくお願いいたします。
>>>
>>> --
>>> 斉藤 学 (Saito, Manabu)
>>> 東京大学 情報理工学系研究科 創造情報学専攻 修士2年
>>> mobile:090-3768-2158 e-mail:saito@jsk.t.u-tokyo.ac.jp
>>> 〒113-8656 東京都文京区本郷7-3-1
>>> 工学部二号館73A4(稲葉研究室) tel:03-5841-8360
>>> _______________________________________________
>>> openrtm-users mailing list
>>> openrtm-users@openrtm.org
>>> http://www.openrtm.org/mailman/listinfo/openrtm-users
>>>
>>
>>
>>
>> --
>> 安藤慶昭@独立行政法人産業技術総合研究所 知能システム研究部門
>> 統合知能研究グループ 主任研究員, 博士(工学)
>> 〒305-8568 つくば市梅園1-1-1 中央第2
>> e-mail: n-ando@aist.go.jp, web: http://staff.aist.go.jp/n-ando
>> OpenRTM-aist: http://www.openrtm.org
>>
>> Noriaki Ando, Ph.D.
>> Senior Research Scientist, RT-Synthesis R.G., ISRI, AIST
>> AIST Tsukuba Central 2, Tsukuba, Ibaraki 305-8568 JAPAN
>> e-mail: n-ando@aist.go.jp, web: http://staff.aist.go.jp/n-ando
>> OpenRTM-aist: http://www.openrtm.org
>> _______________________________________________
>> openrtm-users mailing list
>> openrtm-users@openrtm.org
>> http://www.openrtm.org/mailman/listinfo/openrtm-users
>>
>
>
>
_______________________________________________
openrtm-users mailing list
openrtm-users@openrtm.org
http://www.openrtm.org/mailman/listinfo/openrtm-users

Manabu Saito
オフライン
Last seen: なし 前
登録日: 2011-11-14 17:20
[openrtm-users 02343] リアルタイム処理を行うRTCのDataportへの接続で起こる問題の調査方法

ジェフ様

東京大学の斉藤です。
申し訳有りませんが、現在、実機上でRTCが動く環境がありませんので、
実機での結果は木曜日以降にメールで報告させていただきます。

以下はシミュレータの場合ですが、python/rtshell接続したポートの情報(rtcon -ll)です。

-DataOutPort: qOut
dataport.data_type TimedDoubleSeq
dataport.dataflow_type push,pull
dataport.interface_type corba_cdr
dataport.subscription_type flush,new,periodic
port.port_type DataOutPort
-Connected to /localhost/HrpsysSeqStateROSBridge0.rtc:rsangle
Name qOut_rsangle
ID fa477d4a-1734-4d5e-826f-82ce6847afbb
dataport.publisher.push_policy all
dataport.subscription_type new
dataport.interface_type corba_cdr
dataport.data_type TimedDoubleSeq
dataport.dataflow_type push
dataport.serializer.cdr.endian little,big

rtconコマンドで接続した場合です。ジェフ様の例と同じ接続状況です。

-DataOutPort: qOut
dataport.data_type TimedDoubleSeq
dataport.dataflow_type push,pull
dataport.interface_type corba_cdr
dataport.subscription_type flush,new,periodic
port.port_type DataOutPort
-Connected to
/localhost/saito-laptop.host_cxt/manager.mgr/manager/HrpsysSeqStateROSBridge0.rtc:rsangle
Name qOutrsangle
ID 87e0d997-a3c5-468e-97c1-38b035c39a78
dataport.subscription_type new
dataport.interface_type corba_cdr
dataport.dataflow_type push
dataport.data_type TimedDoubleSeq
dataport.serializer.cdr.endian little,big

2011年11月17日9:36 Geoffrey Biggs :
> 斉藤様
>
> ジェフです。
>
> subscription_typeの問題について、こちらでrtshellを手動で
> subscription_typeをnewにできると確認しました。rtmlaunchを使った後、rtcat
> -ll でコネクタのsubscription_typeは何の値かの確認をお願いします。後、手
> 動でrtconで接続したらどの値になるかの確認をお願い致します。例えば:
>
> $ rtcon ConsoleIn0.rtc:out ConsoleOut0.rtc:in -p
> dataport.subscription_type=new
>
> $ rtcat -ll ConsoleIn0.rtc:out
> -DataOutPort: out
> dataport.data_type IDL:RTC/TimedLong:1.0
> dataport.dataflow_type push,pull
> dataport.interface_type corba_cdr
> dataport.subscription_type flush,new,periodic
> port.port_type DataOutPort
> -Connected to /localhost/kenroke.host_cxt/ConsoleOut0.rtc:in
> Name outin
> ID 1936167d-3ab4-4c73-a876-ab2a38c46d65
> dataport.subscription_type new
> dataport.interface_type corba_cdr
> dataport.dataflow_type push
> dataport.data_type IDL:RTC/TimedLong:1.0
> dataport.serializer.cdr.endian little,big
>
> クラッシュの問題は、LinuxやOSXの場合ならgdbでコンポーネントを実行して、
> クラッシュしたら「bt」というコマンドでbacktraceを取ってみてください。
> backtraceでどこにクラッシュしたかが見えます。
>
> よろしくお願いいたします。
>
>
> On 17/11/11 01:37, Manabu Saito wrote:
>> 東京大学の斉藤です。
>> ご返信いただきありがとうございます。
>>
>> 落ちるRTCは送信側/OutPort側のRTCですが、どこで落ちているかはわかっておりません。
>> それを調べるのが一番にすべきことでした...
>>
>> ただ、受信側には接続できていれば得られる出力が一度もないまま、
>> SystemEditorでは灰色表示のゾンビコンポーネントとなっておりました。
>>
>> 2011年11月17日0:30 Ando Noriaki:
>>> 産総研 安藤です
>>> ちなみに、落ちるRTCはInPort側のRTCですか?OutPort側のRTCですか?また、RTCはどこで落ちているかお分かりになりますか?
>>>
>>>
>>> 2011年11月14日17:14 Manabu Saito:
>>>> OpenRTM-usersの皆様
>>>>
>>>> はじめまして、東京大学の斉藤と申します。
>>>>
>>>> OpenHRP3を利用したシミュレーション環境内ロボットと通信していた自作RTCを
>>>> 実際のロボットで動かした際に、ロボット側RTCとの通信が出来なくなるということが起こりました。
>>>> この現象について、subscription_typeがデフォルトのflushのままだと
>>>> リアルタイム側に問題が起こるということを詳しい方から聞き、newにして接続することで解決しました.
>>>> (データの送信を別スレッドで行う必要があるようです)
>>>>
>>>> RTSystemEditorをつかって手動でつなげる場合は,これでうまくいくのですが,
>>>> rtshellでsubscription_typeをnewにしたデータポートの接続をすると、
>>>> どうやらRTCがクラッシュしているようなのですが、
>>>> どのように問題を調査すればいいかの指針を皆様に伺いたく存じます。
>>>>
>>>> 抜粋すると以下のようなスクリプトになっており、これで接続ができていないようです。
>>>> (svn co https://rtm-ros-robotics.googlecode.com/svn/trunk/rtmros_common/openrtm/scripts
>>>> の rtmlaunch.py)
>>>>
>>>> props = {'dataport.subscription_type': 'new'}
>>>> options = optparse.Values({'verbose': False, 'id': '', 'name':None,
>>>> 'properties': props})
>>>> rtcon.connect_ports(source_path, source_full_path,
>>>> dest_path,dest_full_path, options, tree=None)
>>>>
>>>> 一方jythonのインタフェースを利用した接続スクリプトを書くと動きました。
>>>> (svn co https://rtm-ros-robotics.googlecode.com/svn/trunk/rtmros_commonの
>>>> hrpsys/bin/hrpsyspyを実行し、hrpsys_ros_bridge/scripts のhrpsys-bridge-connect.pyをロード)
>>>>
>>>> connectPorts(findRTC(node1).port(port1),findRTC(node2).port(port2),
>>>> subscription='new')
>>>>
>>>> Dataportの接続について知識不足なこともあり、リアルタイムの問題ともrtshellの問題とも切り分けられておりません。
>>>> なにか似たような現象などをご存知の方は、お教えいただきたく思います。
>>>>
>>>> よろしくお願いいたします。
>>>>
>>>> --
>>>> 斉藤 学 (Saito, Manabu)
>>>> 東京大学 情報理工学系研究科 創造情報学専攻 修士2年
>>>> mobile:090-3768-2158 e-mail:saito@jsk.t.u-tokyo.ac.jp
>>>> 〒113-8656 東京都文京区本郷7-3-1
>>>> 工学部二号館73A4(稲葉研究室) tel:03-5841-8360
>>>> _______________________________________________
>>>> openrtm-users mailing list
>>>> openrtm-users@openrtm.org
>>>> http://www.openrtm.org/mailman/listinfo/openrtm-users
>>>>
>>>
>>>
>>>
>>> --
>>> 安藤慶昭@独立行政法人産業技術総合研究所 知能システム研究部門
>>> 統合知能研究グループ 主任研究員, 博士(工学)
>>> 〒305-8568 つくば市梅園1-1-1 中央第2
>>> e-mail: n-ando@aist.go.jp, web: http://staff.aist.go.jp/n-ando
>>> OpenRTM-aist: http://www.openrtm.org
>>>
>>> Noriaki Ando, Ph.D.
>>> Senior Research Scientist, RT-Synthesis R.G., ISRI, AIST
>>> AIST Tsukuba Central 2, Tsukuba, Ibaraki 305-8568 JAPAN
>>> e-mail: n-ando@aist.go.jp, web: http://staff.aist.go.jp/n-ando
>>> OpenRTM-aist: http://www.openrtm.org
>>> _______________________________________________
>>> openrtm-users mailing list
>>> openrtm-users@openrtm.org
>>> http://www.openrtm.org/mailman/listinfo/openrtm-users
>>>
>>
>>
>>
> _______________________________________________
> openrtm-users mailing list
> openrtm-users@openrtm.org
> http://www.openrtm.org/mailman/listinfo/openrtm-users
>

Shunichi Nozawa
オフライン
Last seen: なし 前
登録日: 2011-06-01 20:20
[openrtm-users 02445] リアルタイム処理を行うRTCのDataportへの接続で起こる問題の調査方法

ジェフ様、東京大学の野沢です。
お世話になっております。

表題の件ですが、こちらでいくつか調査・進展した
事項がございますので、私からご報告させていただきます。
メーリスに投稿させていただいてからしばし時間が経過したしましたので、
整理しながらご報告させていただきます。

ロボット体内(Art-Linux)のRTCと
外部PCのRTCとのデータポート接続を行う際に、
rtshellのrtconでsub_typeが'new'だとして

props = {'dataport.subscription_type': sub_type}
options = optparse.Values({'verbose': False, 'id': '', 'name':None,
'properties': props})
rtcon.connect_ports(source_path, source_full_path,
dest_path,dest_full_path, options, tree=None)

のように接続を行うと

1. データポートがrtsystem editor上ではつながっているが
データが流れてこない(isNewにならない)
2. 外部PCのRTCを落とすと、体内RTCが落ちる
"落ちる"現象は、一切の通信ができなくなる
(rtcatできない、system editor上でクリックできずフリーズする)

となり、connectPortsで

connectPorts(findRTC(node1).port(port1),findRTC(node2).port(port2),
subscription='new')

とするとその問題1.と2.が起きないというものでした。

こちらでいくつか調べましたところ、
rtcon.connect_portsをpythonで使用する際の
文字コードが問題だったようです。

上記のsub_typeに
- pythonのunicode型のu'new'が入っていると1.と2.の症状がおき
- 'new'になっているとrtcon.connect_portsを使用しても問題がでなくなりました。

こちらの環境では、添付のようなスクリプトで
# workの部分をコメントインすると正しく動作し、
# does not workの部分をコメントインすると問題1.2.がおきるのが
確認できました。
なお、問題1.2.が起きている状態でもうまくいっている状態でも
rtsystem editor上では違いが見られませんでした。
以下にrtcatしたログを付します。
basePosの部分が該当データポートなのですが、
rtcat上でもうまくいく場合いかない場合の
接続状況表示の差はみられませんでした。

# workでtest_rtcon.pyを実行
leus@kentucky:~$ rtcat -ll /hrp4001c/StateHolder0.rtc:basePosOut
-DataOutPort: basePosOut
dataport.data_type TimedDoubleSeq
dataport.dataflow_type push,pull
dataport.interface_type corba_cdr
dataport.subscription_type flush,new,periodic
port.port_type DataOutPort
-Connected to /hrp4001c/hrp4001c.host_cxt/manager.mgr/seq.rtc:basePosInit
Name connector0
ID 1a0c3d9d-8073-4227-9a62-f677b2437cb8
dataport.subscription_type flush
dataport.buffer.length 1
dataport.interface_type corba_cdr
dataport.dataflow_type Push
dataport.serializer.cdr.endian little,big
-Connected to /hrp4001c/hrp4001c.host_cxt/manager.mgr/kpg.rtc:pInit
Name connector0
ID dfa950ea-2452-460f-b036-35d4e2938e2e
dataport.subscription_type flush
dataport.buffer.length 1
dataport.interface_type corba_cdr
dataport.dataflow_type Push
dataport.serializer.cdr.endian little,big
-Connected to /hrp4001c/hrp4001c.host_cxt/manager.mgr/log.rtc:basePos
Name connector0
ID 5fa59617-9eeb-4132-b1ae-48eaf22aa50a
dataport.subscription_type flush
dataport.buffer.length 1
dataport.interface_type corba_cdr
dataport.dataflow_type Push
dataport.serializer.cdr.endian little,big
-Connected to /hrp4001c/HRP4RStateHolder0.rtc:basePos
Name basePosOut_basePos
ID ecfdf0c7-a4b0-4f0f-b883-b266fc97cfca
dataport.subscription_type new
dataport.interface_type corba_cdr
dataport.dataflow_type push
dataport.data_type TimedDoubleSeq
dataport.serializer.cdr.endian little,big

# does not workでtest_rtcon.pyを実行
leus@kentucky:~$ rtcat -ll /hrp4001c/StateHolder0.rtc:basePosOut
-DataOutPort: basePosOut
dataport.data_type TimedDoubleSeq
dataport.dataflow_type push,pull
dataport.interface_type corba_cdr
dataport.subscription_type flush,new,periodic
port.port_type DataOutPort
-Connected to /hrp4001c/hrp4001c.host_cxt/manager.mgr/seq.rtc:basePosInit
Name connector0
ID ba68a33d-af6b-4965-9e37-c72a433b5596
dataport.subscription_type flush
dataport.buffer.length 1
dataport.interface_type corba_cdr
dataport.dataflow_type Push
dataport.serializer.cdr.endian little,big
-Connected to /hrp4001c/hrp4001c.host_cxt/manager.mgr/kpg.rtc:pInit
Name connector0
ID 37d3b48a-a084-460f-bf51-86f190372cfc
dataport.subscription_type flush
dataport.buffer.length 1
dataport.interface_type corba_cdr
dataport.dataflow_type Push
dataport.serializer.cdr.endian little,big
-Connected to /hrp4001c/hrp4001c.host_cxt/manager.mgr/log.rtc:basePos
Name connector0
ID c84bb61f-18d3-4bac-a1cb-180000000000
dataport.subscription_type flush
dataport.buffer.length 1
dataport.interface_type corba_cdr
dataport.dataflow_type Push
dataport.serializer.cdr.endian little,big
-Connected to /hrp4001c/HRP4RStateHolder0.rtc:basePos
Name basePosOut_basePos
ID 520fbf98-4ddf-454c-890d-6efe08ec77af
dataport.subscription_type new
dataport.interface_type corba_cdr
dataport.dataflow_type push
dataport.data_type TimedDoubleSeq
dataport.serializer.cdr.endian little,big

なお、同様にunicodeの文字列を

connectPorts(findRTC(node1).port(port1),findRTC(node2).port(port2),
subscription=u'new')

のようにconnecPortsに与えて見たところ、
こちらでは1.2.の問題がおきませんでした。

長文となりましたが、よろしくお願いいたします。

2011年11月21日8:55 Manabu Saito :
> ジェフ様
>
> 東京大学の斉藤です。
> 申し訳有りませんが、現在、実機上でRTCが動く環境がありませんので、
> 実機での結果は木曜日以降にメールで報告させていただきます。
>
> 以下はシミュレータの場合ですが、python/rtshell接続したポートの情報(rtcon -ll)です。
>
> -DataOutPort: qOut
> dataport.data_type TimedDoubleSeq
> dataport.dataflow_type push,pull
> dataport.interface_type corba_cdr
> dataport.subscription_type flush,new,periodic
> port.port_type DataOutPort
> -Connected to /localhost/HrpsysSeqStateROSBridge0.rtc:rsangle
> Name qOut_rsangle
> ID fa477d4a-1734-4d5e-826f-82ce6847afbb
> dataport.publisher.push_policy all
> dataport.subscription_type new
> dataport.interface_type corba_cdr
> dataport.data_type TimedDoubleSeq
> dataport.dataflow_type push
> dataport.serializer.cdr.endian little,big
>
> rtconコマンドで接続した場合です。ジェフ様の例と同じ接続状況です。
>
> -DataOutPort: qOut
> dataport.data_type TimedDoubleSeq
> dataport.dataflow_type push,pull
> dataport.interface_type corba_cdr
> dataport.subscription_type flush,new,periodic
> port.port_type DataOutPort
> -Connected to
> /localhost/saito-laptop.host_cxt/manager.mgr/manager/HrpsysSeqStateROSBridge0.rtc:rsangle
> Name qOutrsangle
> ID 87e0d997-a3c5-468e-97c1-38b035c39a78
> dataport.subscription_type new
> dataport.interface_type corba_cdr
> dataport.dataflow_type push
> dataport.data_type TimedDoubleSeq
> dataport.serializer.cdr.endian little,big
>
>
> 2011年11月17日9:36 Geoffrey Biggs :
>> 斉藤様
>>
>> ジェフです。
>>
>> subscription_typeの問題について、こちらでrtshellを手動で
>> subscription_typeをnewにできると確認しました。rtmlaunchを使った後、rtcat
>> -ll でコネクタのsubscription_typeは何の値かの確認をお願いします。後、手
>> 動でrtconで接続したらどの値になるかの確認をお願い致します。例えば:
>>
>> $ rtcon ConsoleIn0.rtc:out ConsoleOut0.rtc:in -p
>> dataport.subscription_type=new
>>
>> $ rtcat -ll ConsoleIn0.rtc:out
>> -DataOutPort: out
>> dataport.data_type IDL:RTC/TimedLong:1.0
>> dataport.dataflow_type push,pull
>> dataport.interface_type corba_cdr
>> dataport.subscription_type flush,new,periodic
>> port.port_type DataOutPort
>> -Connected to /localhost/kenroke.host_cxt/ConsoleOut0.rtc:in
>> Name outin
>> ID 1936167d-3ab4-4c73-a876-ab2a38c46d65
>> dataport.subscription_type new
>> dataport.interface_type corba_cdr
>> dataport.dataflow_type push
>> dataport.data_type IDL:RTC/TimedLong:1.0
>> dataport.serializer.cdr.endian little,big
>>
>> クラッシュの問題は、LinuxやOSXの場合ならgdbでコンポーネントを実行して、
>> クラッシュしたら「bt」というコマンドでbacktraceを取ってみてください。
>> backtraceでどこにクラッシュしたかが見えます。
>>
>> よろしくお願いいたします。
>>
>>
>> On 17/11/11 01:37, Manabu Saito wrote:
>>> 東京大学の斉藤です。
>>> ご返信いただきありがとうございます。
>>>
>>> 落ちるRTCは送信側/OutPort側のRTCですが、どこで落ちているかはわかっておりません。
>>> それを調べるのが一番にすべきことでした...
>>>
>>> ただ、受信側には接続できていれば得られる出力が一度もないまま、
>>> SystemEditorでは灰色表示のゾンビコンポーネントとなっておりました。
>>>
>>> 2011年11月17日0:30 Ando Noriaki:
>>>> 産総研 安藤です
>>>> ちなみに、落ちるRTCはInPort側のRTCですか?OutPort側のRTCですか?また、RTCはどこで落ちているかお分かりになりますか?
>>>>
>>>>
>>>> 2011年11月14日17:14 Manabu Saito:
>>>>> OpenRTM-usersの皆様
>>>>>
>>>>> はじめまして、東京大学の斉藤と申します。
>>>>>
>>>>> OpenHRP3を利用したシミュレーション環境内ロボットと通信していた自作RTCを
>>>>> 実際のロボットで動かした際に、ロボット側RTCとの通信が出来なくなるということが起こりました。
>>>>> この現象について、subscription_typeがデフォルトのflushのままだと
>>>>> リアルタイム側に問題が起こるということを詳しい方から聞き、newにして接続することで解決しました.
>>>>> (データの送信を別スレッドで行う必要があるようです)
>>>>>
>>>>> RTSystemEditorをつかって手動でつなげる場合は,これでうまくいくのですが,
>>>>> rtshellでsubscription_typeをnewにしたデータポートの接続をすると、
>>>>> どうやらRTCがクラッシュしているようなのですが、
>>>>> どのように問題を調査すればいいかの指針を皆様に伺いたく存じます。
>>>>>
>>>>> 抜粋すると以下のようなスクリプトになっており、これで接続ができていないようです。
>>>>> (svn co https://rtm-ros-robotics.googlecode.com/svn/trunk/rtmros_common/openrtm/scripts
>>>>> の rtmlaunch.py)
>>>>>
>>>>> props = {'dataport.subscription_type': 'new'}
>>>>> options = optparse.Values({'verbose': False, 'id': '', 'name':None,
>>>>> 'properties': props})
>>>>> rtcon.connect_ports(source_path, source_full_path,
>>>>> dest_path,dest_full_path, options, tree=None)
>>>>>
>>>>> 一方jythonのインタフェースを利用した接続スクリプトを書くと動きました。
>>>>> (svn co https://rtm-ros-robotics.googlecode.com/svn/trunk/rtmros_commonの
>>>>> hrpsys/bin/hrpsyspyを実行し、hrpsys_ros_bridge/scripts のhrpsys-bridge-connect.pyをロード)
>>>>>
>>>>> connectPorts(findRTC(node1).port(port1),findRTC(node2).port(port2),
>>>>> subscription='new')
>>>>>
>>>>> Dataportの接続について知識不足なこともあり、リアルタイムの問題ともrtshellの問題とも切り分けられておりません。
>>>>> なにか似たような現象などをご存知の方は、お教えいただきたく思います。
>>>>>
>>>>> よろしくお願いいたします。
>>>>>
>>>>> --
>>>>> 斉藤 学 (Saito, Manabu)
>>>>> 東京大学 情報理工学系研究科 創造情報学専攻 修士2年
>>>>> mobile:090-3768-2158 e-mail:saito@jsk.t.u-tokyo.ac.jp
>>>>> 〒113-8656 東京都文京区本郷7-3-1
>>>>> 工学部二号館73A4(稲葉研究室) tel:03-5841-8360
>>>>> _______________________________________________
>>>>> openrtm-users mailing list
>>>>> openrtm-users@openrtm.org
>>>>> http://www.openrtm.org/mailman/listinfo/openrtm-users
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 安藤慶昭@独立行政法人産業技術総合研究所 知能システム研究部門
>>>> 統合知能研究グループ 主任研究員, 博士(工学)
>>>> 〒305-8568 つくば市梅園1-1-1 中央第2
>>>> e-mail: n-ando@aist.go.jp, web: http://staff.aist.go.jp/n-ando
>>>> OpenRTM-aist: http://www.openrtm.org
>>>>
>>>> Noriaki Ando, Ph.D.
>>>> Senior Research Scientist, RT-Synthesis R.G., ISRI, AIST
>>>> AIST Tsukuba Central 2, Tsukuba, Ibaraki 305-8568 JAPAN
>>>> e-mail: n-ando@aist.go.jp, web: http://staff.aist.go.jp/n-ando
>>>> OpenRTM-aist: http://www.openrtm.org
>>>> _______________________________________________
>>>> openrtm-users mailing list
>>>> openrtm-users@openrtm.org
>>>> http://www.openrtm.org/mailman/listinfo/openrtm-users
>>>>
>>>
>>>
>>>
>> _______________________________________________
>> openrtm-users mailing list
>> openrtm-users@openrtm.org
>> http://www.openrtm.org/mailman/listinfo/openrtm-users
>>
>
>
>
> --
> 斉藤 学 (Saito, Manabu)
> 東京大学 情報理工学系研究科 創造情報学専攻 修士2年
> mobile:090-3768-2158 e-mail:saito@jsk.t.u-tokyo.ac.jp
> 〒113-8656 東京都文京区本郷7-3-1
> 工学部二号館73A4(稲葉研究室) tel:03-5841-8360
> _______________________________________________
> openrtm-users mailing list
> openrtm-users@openrtm.org
> http://www.openrtm.org/mailman/listinfo/openrtm-users

gbiggs
オフライン
Last seen: 6年 9ヶ月 前
登録日: 2010-08-02 07:51
[openrtm-users 02453] リアルタイム処理を行うRTCのDataportへの接続で起こる問題の調査方法

野沢様

ジェフです。

情報でありがとうございます。

Pythonのunicode stringを使うとomniORBはよく問題になります。unicode
stringとただのstringは違うデータを持つが、omniORBは区別なしで両方を普通
のstringとして処理します。したがって、データがRTCがわについたら普通の
stringとして使おうとしますが、もうASCIIの「new」ではなくて別のデータで
す。多分これでエラーになります。その上、rtcatでポートの状態を見たら、
unicodeデータは帰ってきて、pythonはちゃんとunicodeだと理解して「new」を
表示するからRTCがわで違うデータだと見えません。

以上の仮説を確認したがりましたら、RTCが出すログファイルにコネクションの
プロパティを見る方が一番早いです。

これからrtctreeですべてのstringを普通の方に変更させることを検討します。

よろしくお願いいたします。

On 13/02/12 19:57, Shunichi Nozawa wrote:
> ジェフ様、東京大学の野沢です。
> お世話になっております。
>
> 表題の件ですが、こちらでいくつか調査・進展した
> 事項がございますので、私からご報告させていただきます。
> メーリスに投稿させていただいてからしばし時間が経過したしましたので、
> 整理しながらご報告させていただきます。
>
> ロボット体内(Art-Linux)のRTCと
> 外部PCのRTCとのデータポート接続を行う際に、
> rtshellのrtconでsub_typeが'new'だとして
>
> props = {'dataport.subscription_type': sub_type}
> options = optparse.Values({'verbose': False, 'id': '', 'name':None,
> 'properties': props})
> rtcon.connect_ports(source_path, source_full_path,
> dest_path,dest_full_path, options, tree=None)
>
> のように接続を行うと
>
> 1. データポートがrtsystem editor上ではつながっているが
> データが流れてこない(isNewにならない)
> 2. 外部PCのRTCを落とすと、体内RTCが落ちる
> "落ちる"現象は、一切の通信ができなくなる
> (rtcatできない、system editor上でクリックできずフリーズする)
>
> となり、connectPortsで
>
> connectPorts(findRTC(node1).port(port1),findRTC(node2).port(port2),
> subscription='new')
>
> とするとその問題1.と2.が起きないというものでした。
>
>
> こちらでいくつか調べましたところ、
> rtcon.connect_portsをpythonで使用する際の
> 文字コードが問題だったようです。
>
> 上記のsub_typeに
> - pythonのunicode型のu'new'が入っていると1.と2.の症状がおき
> - 'new'になっているとrtcon.connect_portsを使用しても問題がでなくなりました。
>
>
> こちらの環境では、添付のようなスクリプトで
> # workの部分をコメントインすると正しく動作し、
> # does not workの部分をコメントインすると問題1.2.がおきるのが
> 確認できました。
> なお、問題1.2.が起きている状態でもうまくいっている状態でも
> rtsystem editor上では違いが見られませんでした。
> 以下にrtcatしたログを付します。
> basePosの部分が該当データポートなのですが、
> rtcat上でもうまくいく場合いかない場合の
> 接続状況表示の差はみられませんでした。
>
>
> # workでtest_rtcon.pyを実行
> leus@kentucky:~$ rtcat -ll /hrp4001c/StateHolder0.rtc:basePosOut
> -DataOutPort: basePosOut
> dataport.data_type TimedDoubleSeq
> dataport.dataflow_type push,pull
> dataport.interface_type corba_cdr
> dataport.subscription_type flush,new,periodic
> port.port_type DataOutPort
> -Connected to /hrp4001c/hrp4001c.host_cxt/manager.mgr/seq.rtc:basePosInit
> Name connector0
> ID 1a0c3d9d-8073-4227-9a62-f677b2437cb8
> dataport.subscription_type flush
> dataport.buffer.length 1
> dataport.interface_type corba_cdr
> dataport.dataflow_type Push
> dataport.serializer.cdr.endian little,big
> -Connected to /hrp4001c/hrp4001c.host_cxt/manager.mgr/kpg.rtc:pInit
> Name connector0
> ID dfa950ea-2452-460f-b036-35d4e2938e2e
> dataport.subscription_type flush
> dataport.buffer.length 1
> dataport.interface_type corba_cdr
> dataport.dataflow_type Push
> dataport.serializer.cdr.endian little,big
> -Connected to /hrp4001c/hrp4001c.host_cxt/manager.mgr/log.rtc:basePos
> Name connector0
> ID 5fa59617-9eeb-4132-b1ae-48eaf22aa50a
> dataport.subscription_type flush
> dataport.buffer.length 1
> dataport.interface_type corba_cdr
> dataport.dataflow_type Push
> dataport.serializer.cdr.endian little,big
> -Connected to /hrp4001c/HRP4RStateHolder0.rtc:basePos
> Name basePosOut_basePos
> ID ecfdf0c7-a4b0-4f0f-b883-b266fc97cfca
> dataport.subscription_type new
> dataport.interface_type corba_cdr
> dataport.dataflow_type push
> dataport.data_type TimedDoubleSeq
> dataport.serializer.cdr.endian little,big
>
>
> # does not workでtest_rtcon.pyを実行
> leus@kentucky:~$ rtcat -ll /hrp4001c/StateHolder0.rtc:basePosOut
> -DataOutPort: basePosOut
> dataport.data_type TimedDoubleSeq
> dataport.dataflow_type push,pull
> dataport.interface_type corba_cdr
> dataport.subscription_type flush,new,periodic
> port.port_type DataOutPort
> -Connected to /hrp4001c/hrp4001c.host_cxt/manager.mgr/seq.rtc:basePosInit
> Name connector0
> ID ba68a33d-af6b-4965-9e37-c72a433b5596
> dataport.subscription_type flush
> dataport.buffer.length 1
> dataport.interface_type corba_cdr
> dataport.dataflow_type Push
> dataport.serializer.cdr.endian little,big
> -Connected to /hrp4001c/hrp4001c.host_cxt/manager.mgr/kpg.rtc:pInit
> Name connector0
> ID 37d3b48a-a084-460f-bf51-86f190372cfc
> dataport.subscription_type flush
> dataport.buffer.length 1
> dataport.interface_type corba_cdr
> dataport.dataflow_type Push
> dataport.serializer.cdr.endian little,big
> -Connected to /hrp4001c/hrp4001c.host_cxt/manager.mgr/log.rtc:basePos
> Name connector0
> ID c84bb61f-18d3-4bac-a1cb-180000000000
> dataport.subscription_type flush
> dataport.buffer.length 1
> dataport.interface_type corba_cdr
> dataport.dataflow_type Push
> dataport.serializer.cdr.endian little,big
> -Connected to /hrp4001c/HRP4RStateHolder0.rtc:basePos
> Name basePosOut_basePos
> ID 520fbf98-4ddf-454c-890d-6efe08ec77af
> dataport.subscription_type new
> dataport.interface_type corba_cdr
> dataport.dataflow_type push
> dataport.data_type TimedDoubleSeq
> dataport.serializer.cdr.endian little,big
>
>
> なお、同様にunicodeの文字列を
>
> connectPorts(findRTC(node1).port(port1),findRTC(node2).port(port2),
> subscription=u'new')
>
> のようにconnecPortsに与えて見たところ、
> こちらでは1.2.の問題がおきませんでした。
>
>
> 長文となりましたが、よろしくお願いいたします。
>
>
> 2011年11月21日8:55 Manabu Saito:
>> ジェフ様
>>
>> 東京大学の斉藤です。
>> 申し訳有りませんが、現在、実機上でRTCが動く環境がありませんので、
>> 実機での結果は木曜日以降にメールで報告させていただきます。
>>
>> 以下はシミュレータの場合ですが、python/rtshell接続したポートの情報(rtcon -ll)です。
>>
>> -DataOutPort: qOut
>> dataport.data_type TimedDoubleSeq
>> dataport.dataflow_type push,pull
>> dataport.interface_type corba_cdr
>> dataport.subscription_type flush,new,periodic
>> port.port_type DataOutPort
>> -Connected to /localhost/HrpsysSeqStateROSBridge0.rtc:rsangle
>> Name qOut_rsangle
>> ID fa477d4a-1734-4d5e-826f-82ce6847afbb
>> dataport.publisher.push_policy all
>> dataport.subscription_type new
>> dataport.interface_type corba_cdr
>> dataport.data_type TimedDoubleSeq
>> dataport.dataflow_type push
>> dataport.serializer.cdr.endian little,big
>>
>> rtconコマンドで接続した場合です。ジェフ様の例と同じ接続状況です。
>>
>> -DataOutPort: qOut
>> dataport.data_type TimedDoubleSeq
>> dataport.dataflow_type push,pull
>> dataport.interface_type corba_cdr
>> dataport.subscription_type flush,new,periodic
>> port.port_type DataOutPort
>> -Connected to
>> /localhost/saito-laptop.host_cxt/manager.mgr/manager/HrpsysSeqStateROSBridge0.rtc:rsangle
>> Name qOutrsangle
>> ID 87e0d997-a3c5-468e-97c1-38b035c39a78
>> dataport.subscription_type new
>> dataport.interface_type corba_cdr
>> dataport.dataflow_type push
>> dataport.data_type TimedDoubleSeq
>> dataport.serializer.cdr.endian little,big
>>
>>
>> 2011年11月17日9:36 Geoffrey Biggs:
>>> 斉藤様
>>>
>>> ジェフです。
>>>
>>> subscription_typeの問題について、こちらでrtshellを手動で
>>> subscription_typeをnewにできると確認しました。rtmlaunchを使った後、rtcat
>>> -ll でコネクタのsubscription_typeは何の値かの確認をお願いします。後、手
>>> 動でrtconで接続したらどの値になるかの確認をお願い致します。例えば:
>>>
>>> $ rtcon ConsoleIn0.rtc:out ConsoleOut0.rtc:in -p
>>> dataport.subscription_type=new
>>>
>>> $ rtcat -ll ConsoleIn0.rtc:out
>>> -DataOutPort: out
>>> dataport.data_type IDL:RTC/TimedLong:1.0
>>> dataport.dataflow_type push,pull
>>> dataport.interface_type corba_cdr
>>> dataport.subscription_type flush,new,periodic
>>> port.port_type DataOutPort
>>> -Connected to /localhost/kenroke.host_cxt/ConsoleOut0.rtc:in
>>> Name outin
>>> ID 1936167d-3ab4-4c73-a876-ab2a38c46d65
>>> dataport.subscription_type new
>>> dataport.interface_type corba_cdr
>>> dataport.dataflow_type push
>>> dataport.data_type IDL:RTC/TimedLong:1.0
>>> dataport.serializer.cdr.endian little,big
>>>
>>> クラッシュの問題は、LinuxやOSXの場合ならgdbでコンポーネントを実行して、
>>> クラッシュしたら「bt」というコマンドでbacktraceを取ってみてください。
>>> backtraceでどこにクラッシュしたかが見えます。
>>>
>>> よろしくお願いいたします。
>>>
>>>
>>> On 17/11/11 01:37, Manabu Saito wrote:
>>>> 東京大学の斉藤です。
>>>> ご返信いただきありがとうございます。
>>>>
>>>> 落ちるRTCは送信側/OutPort側のRTCですが、どこで落ちているかはわかっておりません。
>>>> それを調べるのが一番にすべきことでした...
>>>>
>>>> ただ、受信側には接続できていれば得られる出力が一度もないまま、
>>>> SystemEditorでは灰色表示のゾンビコンポーネントとなっておりました。
>>>>
>>>> 2011年11月17日0:30 Ando Noriaki:
>>>>> 産総研 安藤です
>>>>> ちなみに、落ちるRTCはInPort側のRTCですか?OutPort側のRTCですか?また、RTCはどこで落ちているかお分かりになりますか?
>>>>>
>>>>>
>>>>> 2011年11月14日17:14 Manabu Saito:
>>>>>> OpenRTM-usersの皆様
>>>>>>
>>>>>> はじめまして、東京大学の斉藤と申します。
>>>>>>
>>>>>> OpenHRP3を利用したシミュレーション環境内ロボットと通信していた自作RTCを
>>>>>> 実際のロボットで動かした際に、ロボット側RTCとの通信が出来なくなるということが起こりました。
>>>>>> この現象について、subscription_typeがデフォルトのflushのままだと
>>>>>> リアルタイム側に問題が起こるということを詳しい方から聞き、newにして接続することで解決しました.
>>>>>> (データの送信を別スレッドで行う必要があるようです)
>>>>>>
>>>>>> RTSystemEditorをつかって手動でつなげる場合は,これでうまくいくのですが,
>>>>>> rtshellでsubscription_typeをnewにしたデータポートの接続をすると、
>>>>>> どうやらRTCがクラッシュしているようなのですが、
>>>>>> どのように問題を調査すればいいかの指針を皆様に伺いたく存じます。
>>>>>>
>>>>>> 抜粋すると以下のようなスクリプトになっており、これで接続ができていないようです。
>>>>>> (svn co https://rtm-ros-robotics.googlecode.com/svn/trunk/rtmros_common/openrtm/scripts
>>>>>> の rtmlaunch.py)
>>>>>>
>>>>>> props = {'dataport.subscription_type': 'new'}
>>>>>> options = optparse.Values({'verbose': False, 'id': '', 'name':None,
>>>>>> 'properties': props})
>>>>>> rtcon.connect_ports(source_path, source_full_path,
>>>>>> dest_path,dest_full_path, options, tree=None)
>>>>>>
>>>>>> 一方jythonのインタフェースを利用した接続スクリプトを書くと動きました。
>>>>>> (svn co https://rtm-ros-robotics.googlecode.com/svn/trunk/rtmros_commonの
>>>>>> hrpsys/bin/hrpsyspyを実行し、hrpsys_ros_bridge/scripts のhrpsys-bridge-connect.pyをロード)
>>>>>>
>>>>>> connectPorts(findRTC(node1).port(port1),findRTC(node2).port(port2),
>>>>>> subscription='new')
>>>>>>
>>>>>> Dataportの接続について知識不足なこともあり、リアルタイムの問題ともrtshellの問題とも切り分けられておりません。
>>>>>> なにか似たような現象などをご存知の方は、お教えいただきたく思います。
>>>>>>
>>>>>> よろしくお願いいたします。
>>>>>>
>>>>>> --
>>>>>> 斉藤 学 (Saito, Manabu)
>>>>>> 東京大学 情報理工学系研究科 創造情報学専攻 修士2年
>>>>>> mobile:090-3768-2158 e-mail:saito@jsk.t.u-tokyo.ac.jp
>>>>>> 〒113-8656 東京都文京区本郷7-3-1
>>>>>> 工学部二号館73A4(稲葉研究室) tel:03-5841-8360
>>>>>> _______________________________________________
>>>>>> openrtm-users mailing list
>>>>>> openrtm-users@openrtm.org
>>>>>> http://www.openrtm.org/mailman/listinfo/openrtm-users
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 安藤慶昭@独立行政法人産業技術総合研究所 知能システム研究部門
>>>>> 統合知能研究グループ 主任研究員, 博士(工学)
>>>>> 〒305-8568 つくば市梅園1-1-1 中央第2
>>>>> e-mail: n-ando@aist.go.jp, web: http://staff.aist.go.jp/n-ando
>>>>> OpenRTM-aist: http://www.openrtm.org
>>>>>
>>>>> Noriaki Ando, Ph.D.
>>>>> Senior Research Scientist, RT-Synthesis R.G., ISRI, AIST
>>>>> AIST Tsukuba Central 2, Tsukuba, Ibaraki 305-8568 JAPAN
>>>>> e-mail: n-ando@aist.go.jp, web: http://staff.aist.go.jp/n-ando
>>>>> OpenRTM-aist: http://www.openrtm.org
>>>>> _______________________________________________
>>>>> openrtm-users mailing list
>>>>> openrtm-users@openrtm.org
>>>>> http://www.openrtm.org/mailman/listinfo/openrtm-users
>>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> openrtm-users mailing list
>>> openrtm-users@openrtm.org
>>> http://www.openrtm.org/mailman/listinfo/openrtm-users
>>>
>>
>>
>>
>> --
>> 斉藤 学 (Saito, Manabu)
>> 東京大学 情報理工学系研究科 創造情報学専攻 修士2年
>> mobile:090-3768-2158 e-mail:saito@jsk.t.u-tokyo.ac.jp
>> 〒113-8656 東京都文京区本郷7-3-1
>> 工学部二号館73A4(稲葉研究室) tel:03-5841-8360
>> _______________________________________________
>> openrtm-users mailing list
>> openrtm-users@openrtm.org
>> http://www.openrtm.org/mailman/listinfo/openrtm-users
>>
>>
>> _______________________________________________
>> openrtm-users mailing list
>> openrtm-users@openrtm.org
>> http://www.openrtm.org/mailman/listinfo/openrtm-users
_______________________________________________
openrtm-users mailing list
openrtm-users@openrtm.org
http://www.openrtm.org/mailman/listinfo/openrtm-users

Shunichi Nozawa
オフライン
Last seen: なし 前
登録日: 2011-06-01 20:20
[openrtm-users 02457] リアルタイム処理を行うRTCのDataportへの接続で起こる問題の調査方法

ジェフ様、野沢です。

> これからrtctreeですべてのstringを普通の方に変更させることを検討します。
こちらの方、よろしくお願いいたします。

unicode string の部分の箇所は、こちらのプログラムで
unicodeでないstringに変換することで解決いたしました。

ありがとうございました。

2012年2月17日10:41 Geoffrey Biggs :
> 野沢様
>
> ジェフです。
>
> 情報でありがとうございます。
>
> Pythonのunicode stringを使うとomniORBはよく問題になります。unicode
> stringとただのstringは違うデータを持つが、omniORBは区別なしで両方を普通
> のstringとして処理します。したがって、データがRTCがわについたら普通の
> stringとして使おうとしますが、もうASCIIの「new」ではなくて別のデータで
> す。多分これでエラーになります。その上、rtcatでポートの状態を見たら、
> unicodeデータは帰ってきて、pythonはちゃんとunicodeだと理解して「new」を
> 表示するからRTCがわで違うデータだと見えません。
>
> 以上の仮説を確認したがりましたら、RTCが出すログファイルにコネクションの
> プロパティを見る方が一番早いです。
>
> これからrtctreeですべてのstringを普通の方に変更させることを検討します。
>
> よろしくお願いいたします。
>
> On 13/02/12 19:57, Shunichi Nozawa wrote:
>> ジェフ様、東京大学の野沢です。
>> お世話になっております。
>>
>> 表題の件ですが、こちらでいくつか調査・進展した
>> 事項がございますので、私からご報告させていただきます。
>> メーリスに投稿させていただいてからしばし時間が経過したしましたので、
>> 整理しながらご報告させていただきます。
>>
>> ロボット体内(Art-Linux)のRTCと
>> 外部PCのRTCとのデータポート接続を行う際に、
>> rtshellのrtconでsub_typeが'new'だとして
>>
>> props = {'dataport.subscription_type': sub_type}
>> options = optparse.Values({'verbose': False, 'id': '', 'name':None,
>> 'properties': props})
>> rtcon.connect_ports(source_path, source_full_path,
>> dest_path,dest_full_path, options, tree=None)
>>
>> のように接続を行うと
>>
>> 1. データポートがrtsystem editor上ではつながっているが
>> データが流れてこない(isNewにならない)
>> 2. 外部PCのRTCを落とすと、体内RTCが落ちる
>> "落ちる"現象は、一切の通信ができなくなる
>> (rtcatできない、system editor上でクリックできずフリーズする)
>>
>> となり、connectPortsで
>>
>> connectPorts(findRTC(node1).port(port1),findRTC(node2).port(port2),
>> subscription='new')
>>
>> とするとその問題1.と2.が起きないというものでした。
>>
>>
>> こちらでいくつか調べましたところ、
>> rtcon.connect_portsをpythonで使用する際の
>> 文字コードが問題だったようです。
>>
>> 上記のsub_typeに
>> - pythonのunicode型のu'new'が入っていると1.と2.の症状がおき
>> - 'new'になっているとrtcon.connect_portsを使用しても問題がでなくなりました。
>>
>>
>> こちらの環境では、添付のようなスクリプトで
>> # workの部分をコメントインすると正しく動作し、
>> # does not workの部分をコメントインすると問題1.2.がおきるのが
>> 確認できました。
>> なお、問題1.2.が起きている状態でもうまくいっている状態でも
>> rtsystem editor上では違いが見られませんでした。
>> 以下にrtcatしたログを付します。
>> basePosの部分が該当データポートなのですが、
>> rtcat上でもうまくいく場合いかない場合の
>> 接続状況表示の差はみられませんでした。
>>
>>
>> # workでtest_rtcon.pyを実行
>> leus@kentucky:~$ rtcat -ll /hrp4001c/StateHolder0.rtc:basePosOut
>> -DataOutPort: basePosOut
>> dataport.data_type TimedDoubleSeq
>> dataport.dataflow_type push,pull
>> dataport.interface_type corba_cdr
>> dataport.subscription_type flush,new,periodic
>> port.port_type DataOutPort
>> -Connected to /hrp4001c/hrp4001c.host_cxt/manager.mgr/seq.rtc:basePosInit
>> Name connector0
>> ID 1a0c3d9d-8073-4227-9a62-f677b2437cb8
>> dataport.subscription_type flush
>> dataport.buffer.length 1
>> dataport.interface_type corba_cdr
>> dataport.dataflow_type Push
>> dataport.serializer.cdr.endian little,big
>> -Connected to /hrp4001c/hrp4001c.host_cxt/manager.mgr/kpg.rtc:pInit
>> Name connector0
>> ID dfa950ea-2452-460f-b036-35d4e2938e2e
>> dataport.subscription_type flush
>> dataport.buffer.length 1
>> dataport.interface_type corba_cdr
>> dataport.dataflow_type Push
>> dataport.serializer.cdr.endian little,big
>> -Connected to /hrp4001c/hrp4001c.host_cxt/manager.mgr/log.rtc:basePos
>> Name connector0
>> ID 5fa59617-9eeb-4132-b1ae-48eaf22aa50a
>> dataport.subscription_type flush
>> dataport.buffer.length 1
>> dataport.interface_type corba_cdr
>> dataport.dataflow_type Push
>> dataport.serializer.cdr.endian little,big
>> -Connected to /hrp4001c/HRP4RStateHolder0.rtc:basePos
>> Name basePosOut_basePos
>> ID ecfdf0c7-a4b0-4f0f-b883-b266fc97cfca
>> dataport.subscription_type new
>> dataport.interface_type corba_cdr
>> dataport.dataflow_type push
>> dataport.data_type TimedDoubleSeq
>> dataport.serializer.cdr.endian little,big
>>
>>
>> # does not workでtest_rtcon.pyを実行
>> leus@kentucky:~$ rtcat -ll /hrp4001c/StateHolder0.rtc:basePosOut
>> -DataOutPort: basePosOut
>> dataport.data_type TimedDoubleSeq
>> dataport.dataflow_type push,pull
>> dataport.interface_type corba_cdr
>> dataport.subscription_type flush,new,periodic
>> port.port_type DataOutPort
>> -Connected to /hrp4001c/hrp4001c.host_cxt/manager.mgr/seq.rtc:basePosInit
>> Name connector0
>> ID ba68a33d-af6b-4965-9e37-c72a433b5596
>> dataport.subscription_type flush
>> dataport.buffer.length 1
>> dataport.interface_type corba_cdr
>> dataport.dataflow_type Push
>> dataport.serializer.cdr.endian little,big
>> -Connected to /hrp4001c/hrp4001c.host_cxt/manager.mgr/kpg.rtc:pInit
>> Name connector0
>> ID 37d3b48a-a084-460f-bf51-86f190372cfc
>> dataport.subscription_type flush
>> dataport.buffer.length 1
>> dataport.interface_type corba_cdr
>> dataport.dataflow_type Push
>> dataport.serializer.cdr.endian little,big
>> -Connected to /hrp4001c/hrp4001c.host_cxt/manager.mgr/log.rtc:basePos
>> Name connector0
>> ID c84bb61f-18d3-4bac-a1cb-180000000000
>> dataport.subscription_type flush
>> dataport.buffer.length 1
>> dataport.interface_type corba_cdr
>> dataport.dataflow_type Push
>> dataport.serializer.cdr.endian little,big
>> -Connected to /hrp4001c/HRP4RStateHolder0.rtc:basePos
>> Name basePosOut_basePos
>> ID 520fbf98-4ddf-454c-890d-6efe08ec77af
>> dataport.subscription_type new
>> dataport.interface_type corba_cdr
>> dataport.dataflow_type push
>> dataport.data_type TimedDoubleSeq
>> dataport.serializer.cdr.endian little,big
>>
>>
>> なお、同様にunicodeの文字列を
>>
>> connectPorts(findRTC(node1).port(port1),findRTC(node2).port(port2),
>> subscription=u'new')
>>
>> のようにconnecPortsに与えて見たところ、
>> こちらでは1.2.の問題がおきませんでした。
>>
>>
>> 長文となりましたが、よろしくお願いいたします。
>>
>>
>> 2011年11月21日8:55 Manabu Saito:
>>> ジェフ様
>>>
>>> 東京大学の斉藤です。
>>> 申し訳有りませんが、現在、実機上でRTCが動く環境がありませんので、
>>> 実機での結果は木曜日以降にメールで報告させていただきます。
>>>
>>> 以下はシミュレータの場合ですが、python/rtshell接続したポートの情報(rtcon -ll)です。
>>>
>>> -DataOutPort: qOut
>>> dataport.data_type TimedDoubleSeq
>>> dataport.dataflow_type push,pull
>>> dataport.interface_type corba_cdr
>>> dataport.subscription_type flush,new,periodic
>>> port.port_type DataOutPort
>>> -Connected to /localhost/HrpsysSeqStateROSBridge0.rtc:rsangle
>>> Name qOut_rsangle
>>> ID fa477d4a-1734-4d5e-826f-82ce6847afbb
>>> dataport.publisher.push_policy all
>>> dataport.subscription_type new
>>> dataport.interface_type corba_cdr
>>> dataport.data_type TimedDoubleSeq
>>> dataport.dataflow_type push
>>> dataport.serializer.cdr.endian little,big
>>>
>>> rtconコマンドで接続した場合です。ジェフ様の例と同じ接続状況です。
>>>
>>> -DataOutPort: qOut
>>> dataport.data_type TimedDoubleSeq
>>> dataport.dataflow_type push,pull
>>> dataport.interface_type corba_cdr
>>> dataport.subscription_type flush,new,periodic
>>> port.port_type DataOutPort
>>> -Connected to
>>> /localhost/saito-laptop.host_cxt/manager.mgr/manager/HrpsysSeqStateROSBridge0.rtc:rsangle
>>> Name qOutrsangle
>>> ID 87e0d997-a3c5-468e-97c1-38b035c39a78
>>> dataport.subscription_type new
>>> dataport.interface_type corba_cdr
>>> dataport.dataflow_type push
>>> dataport.data_type TimedDoubleSeq
>>> dataport.serializer.cdr.endian little,big
>>>
>>>
>>> 2011年11月17日9:36 Geoffrey Biggs:
>>>> 斉藤様
>>>>
>>>> ジェフです。
>>>>
>>>> subscription_typeの問題について、こちらでrtshellを手動で
>>>> subscription_typeをnewにできると確認しました。rtmlaunchを使った後、rtcat
>>>> -ll でコネクタのsubscription_typeは何の値かの確認をお願いします。後、手
>>>> 動でrtconで接続したらどの値になるかの確認をお願い致します。例えば:
>>>>
>>>> $ rtcon ConsoleIn0.rtc:out ConsoleOut0.rtc:in -p
>>>> dataport.subscription_type=new
>>>>
>>>> $ rtcat -ll ConsoleIn0.rtc:out
>>>> -DataOutPort: out
>>>> dataport.data_type IDL:RTC/TimedLong:1.0
>>>> dataport.dataflow_type push,pull
>>>> dataport.interface_type corba_cdr
>>>> dataport.subscription_type flush,new,periodic
>>>> port.port_type DataOutPort
>>>> -Connected to /localhost/kenroke.host_cxt/ConsoleOut0.rtc:in
>>>> Name outin
>>>> ID 1936167d-3ab4-4c73-a876-ab2a38c46d65
>>>> dataport.subscription_type new
>>>> dataport.interface_type corba_cdr
>>>> dataport.dataflow_type push
>>>> dataport.data_type IDL:RTC/TimedLong:1.0
>>>> dataport.serializer.cdr.endian little,big
>>>>
>>>> クラッシュの問題は、LinuxやOSXの場合ならgdbでコンポーネントを実行して、
>>>> クラッシュしたら「bt」というコマンドでbacktraceを取ってみてください。
>>>> backtraceでどこにクラッシュしたかが見えます。
>>>>
>>>> よろしくお願いいたします。
>>>>
>>>>
>>>> On 17/11/11 01:37, Manabu Saito wrote:
>>>>> 東京大学の斉藤です。
>>>>> ご返信いただきありがとうございます。
>>>>>
>>>>> 落ちるRTCは送信側/OutPort側のRTCですが、どこで落ちているかはわかっておりません。
>>>>> それを調べるのが一番にすべきことでした...
>>>>>
>>>>> ただ、受信側には接続できていれば得られる出力が一度もないまま、
>>>>> SystemEditorでは灰色表示のゾンビコンポーネントとなっておりました。
>>>>>
>>>>> 2011年11月17日0:30 Ando Noriaki:
>>>>>> 産総研 安藤です
>>>>>> ちなみに、落ちるRTCはInPort側のRTCですか?OutPort側のRTCですか?また、RTCはどこで落ちているかお分かりになりますか?
>>>>>>
>>>>>>
>>>>>> 2011年11月14日17:14 Manabu Saito:
>>>>>>> OpenRTM-usersの皆様
>>>>>>>
>>>>>>> はじめまして、東京大学の斉藤と申します。
>>>>>>>
>>>>>>> OpenHRP3を利用したシミュレーション環境内ロボットと通信していた自作RTCを
>>>>>>> 実際のロボットで動かした際に、ロボット側RTCとの通信が出来なくなるということが起こりました。
>>>>>>> この現象について、subscription_typeがデフォルトのflushのままだと
>>>>>>> リアルタイム側に問題が起こるということを詳しい方から聞き、newにして接続することで解決しました.
>>>>>>> (データの送信を別スレッドで行う必要があるようです)
>>>>>>>
>>>>>>> RTSystemEditorをつかって手動でつなげる場合は,これでうまくいくのですが,
>>>>>>> rtshellでsubscription_typeをnewにしたデータポートの接続をすると、
>>>>>>> どうやらRTCがクラッシュしているようなのですが、
>>>>>>> どのように問題を調査すればいいかの指針を皆様に伺いたく存じます。
>>>>>>>
>>>>>>> 抜粋すると以下のようなスクリプトになっており、これで接続ができていないようです。
>>>>>>> (svn co https://rtm-ros-robotics.googlecode.com/svn/trunk/rtmros_common/openrtm/scripts
>>>>>>> の rtmlaunch.py)
>>>>>>>
>>>>>>> props = {'dataport.subscription_type': 'new'}
>>>>>>> options = optparse.Values({'verbose': False, 'id': '', 'name':None,
>>>>>>> 'properties': props})
>>>>>>> rtcon.connect_ports(source_path, source_full_path,
>>>>>>> dest_path,dest_full_path, options, tree=None)
>>>>>>>
>>>>>>> 一方jythonのインタフェースを利用した接続スクリプトを書くと動きました。
>>>>>>> (svn co https://rtm-ros-robotics.googlecode.com/svn/trunk/rtmros_commonの
>>>>>>> hrpsys/bin/hrpsyspyを実行し、hrpsys_ros_bridge/scripts のhrpsys-bridge-connect.pyをロード)
>>>>>>>
>>>>>>> connectPorts(findRTC(node1).port(port1),findRTC(node2).port(port2),
>>>>>>> subscription='new')
>>>>>>>
>>>>>>> Dataportの接続について知識不足なこともあり、リアルタイムの問題ともrtshellの問題とも切り分けられておりません。
>>>>>>> なにか似たような現象などをご存知の方は、お教えいただきたく思います。
>>>>>>>
>>>>>>> よろしくお願いいたします。
>>>>>>>
>>>>>>> --
>>>>>>> 斉藤 学 (Saito, Manabu)
>>>>>>> 東京大学 情報理工学系研究科 創造情報学専攻 修士2年
>>>>>>> mobile:090-3768-2158 e-mail:saito@jsk.t.u-tokyo.ac.jp
>>>>>>> 〒113-8656 東京都文京区本郷7-3-1
>>>>>>> 工学部二号館73A4(稲葉研究室) tel:03-5841-8360
>>>>>>> _______________________________________________
>>>>>>> openrtm-users mailing list
>>>>>>> openrtm-users@openrtm.org
>>>>>>> http://www.openrtm.org/mailman/listinfo/openrtm-users
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 安藤慶昭@独立行政法人産業技術総合研究所 知能システム研究部門
>>>>>> 統合知能研究グループ 主任研究員, 博士(工学)
>>>>>> 〒305-8568 つくば市梅園1-1-1 中央第2
>>>>>> e-mail: n-ando@aist.go.jp, web: http://staff.aist.go.jp/n-ando
>>>>>> OpenRTM-aist: http://www.openrtm.org
>>>>>>
>>>>>> Noriaki Ando, Ph.D.
>>>>>> Senior Research Scientist, RT-Synthesis R.G., ISRI, AIST
>>>>>> AIST Tsukuba Central 2, Tsukuba, Ibaraki 305-8568 JAPAN
>>>>>> e-mail: n-ando@aist.go.jp, web: http://staff.aist.go.jp/n-ando
>>>>>> OpenRTM-aist: http://www.openrtm.org
>>>>>> _______________________________________________
>>>>>> openrtm-users mailing list
>>>>>> openrtm-users@openrtm.org
>>>>>> http://www.openrtm.org/mailman/listinfo/openrtm-users
>>>>>>
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> openrtm-users mailing list
>>>> openrtm-users@openrtm.org
>>>> http://www.openrtm.org/mailman/listinfo/openrtm-users
>>>>
>>>
>>>
>>>
>>> --
>>> 斉藤 学 (Saito, Manabu)
>>> 東京大学 情報理工学系研究科 創造情報学専攻 修士2年
>>> mobile:090-3768-2158 e-mail:saito@jsk.t.u-tokyo.ac.jp
>>> 〒113-8656 東京都文京区本郷7-3-1
>>> 工学部二号館73A4(稲葉研究室) tel:03-5841-8360
>>> _______________________________________________
>>> openrtm-users mailing list
>>> openrtm-users@openrtm.org
>>> http://www.openrtm.org/mailman/listinfo/openrtm-users
>>>
>>>
>>> _______________________________________________
>>> openrtm-users mailing list
>>> openrtm-users@openrtm.org
>>> http://www.openrtm.org/mailman/listinfo/openrtm-users
> _______________________________________________
> openrtm-users mailing list
> openrtm-users@openrtm.org
> http://www.openrtm.org/mailman/listinfo/openrtm-users
_______________________________________________
openrtm-users mailing list
openrtm-users@openrtm.org
http://www.openrtm.org/mailman/listinfo/openrtm-users

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

ダウンロード

最新バージョン : 2.0.1-RELESE

統計

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

Choreonoid

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

OpenHRP3

動力学シミュレータ

OpenRTP

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

産総研RTC集

産総研が提供するRTC集

TORK

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

DAQ-Middleware

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