[openrtm-users 02457] Re: リアルタイム処理を行うRTCのDataportへの接続で起こる問題の調査方法
Shunichi Nozawa
nozawa ＠ jsk.t.u-tokyo.ac.jp
2012年 2月 17日 (金) 15:55:10 JST
ジェフ様、野沢です。
> これからrtctreeですべてのstringを普通の方に変更させることを検討します。
こちらの方、よろしくお願いいたします。
unicode string の部分の箇所は、こちらのプログラムで
unicodeでないstringに変換することで解決いたしました。
ありがとうございました。
2012年2月17日10:41 Geoffrey Biggs <geoffrey.biggs ＠ aist.go.jp>:
> 野沢様
>
> ジェフです。
>
> 情報でありがとうございます。
>
> 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<saito ＠ jsk.t.u-tokyo.ac.jp>:
>>> ジェフ様
>>>
>>> 東京大学の斉藤です。
>>> 申し訳有りませんが、現在、実機上で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<geoffrey.biggs ＠ aist.go.jp>:
>>>> 斉藤様
>>>>
>>>> ジェフです。
>>>>
>>>> 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<n-ando ＠ aist.go.jp>:
>>>>>> 産総研 安藤です
>>>>>> ちなみに、落ちるRTCはInPort側のRTCですか？OutPort側のRTCですか？また、RTCはどこで落ちているかお分かりになりますか？
>>>>>>
>>>>>>
>>>>>> 2011年11月14日17:14 Manabu Saito<saito ＠ jsk.t.u-tokyo.ac.jp>:
>>>>>>> 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）
>>>>>>> 東京大学 情報理工学系研究科 創造情報学専攻 修士２年
>>>>>>> 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）
>>> 東京大学 情報理工学系研究科 創造情報学専攻 修士２年
>>> 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 メーリングリストの案内