俵様

安藤です

portServiceList[h]->get_connector_profiles()->length();
を呼ぶ前に
portServiceList[h].out()
を呼んでいませんか？

2009/07/31 10:24 に 俵　崇文＠AIST さんは書きました:
> 清水様
>
> お世話になっております。俵です。
>
>> 何らかの接続はあるようですが、
>> それでもm_connectorsのサイズがゼロだから
>> データ通信が出来ないのですよね。
> はい。
>
>> ConnectorProfileのサイズと
>> m_connectorsのサイズが
>> 一致しているか確かめてみてはどうでしょうか。
>>
>> もしConnectorProfileがある（接続がある）のに
>> m_connectorsがゼロだとすれば、
>> それはRTM側の問題かもしれませんね。
> 件の確認コードでポートごとに
> portServiceList[h]->get_connector_profiles()->length();
> を実行したところ
>
> omniORB: ERROR -- the application attempted to invoke an operation
> on a nil reference.
> と表示される例外が発生しました。
>
> 具体的には、
> get_connector_profiles()
> をコールして、RTCSK.CCファイルの
> RTC::ConnectorProfileList*
> RTC::_objref_PortService::get_connector_profiles()
> の
> _invoke(_call_desc);
> でメッセージが表示されました。
>
> なんらかの原因で接続処理が中途のままということでしょうか？
>
> 以上です。
> よろしくお願いします。
>
> Masayuki Shimizu wrote 2009/07/30 23:33:
>> 俵様
>>
>> 清水です。
>>
>> 何らかの接続はあるようですが、
>> それでもm_connectorsのサイズがゼロだから
>> データ通信が出来ないのですよね。
>>
>> ConnectorProfileのサイズと
>> m_connectorsのサイズが
>> 一致しているか確かめてみてはどうでしょうか。
>>
>> もしConnectorProfileがある（接続がある）のに
>> m_connectorsがゼロだとすれば、
>> それはRTM側の問題かもしれませんね。
>>
>> # もしくはConnectorProfileのサイズと
>> m_connectorsのサイズが一致しない
>> ケースが理論的にあり得るのでしょうか？？？
>> （OpenRTM-aistの開発者の方、教えてください。）
>>
>> 清水
>>
>> --- 俵　崇文＠AIST wrote:
>>
>>> 清水様
>>>
>>> 俵です。
>>>
>>> ご指南ありがとうございます。
>>>
>>>> ConnectorProfile::ports
>>>> を調べて希望通りの接続となっているかを
>>>> 確かめればできます。
>>> 試しに添付ファイルのconsoleOutPortRefInfo.txt
>>> にある通りport等の状態を出力する関数を作成して、
>>> #初歩的なことと存じますが、
>>> #この方法が正しいのか自信がありませんので
>>> #おかしな点がございましたらご指摘願います。
>>> writeする直前に実行してみました。
>>> 出力結果は添付ファイルResult.txtとなりましたが、
>>> 具体的に接続状態を判別する方法がわかりませんので、
>>> ご教示願います。
>>>
>>>
>>>> それと、接続プログラムの、
>>>> CORBA_SeqUtil::push_back(cprof.properties,
>>>> NVUtil::newNV("dataport.dataflow_type",
>>>> "Push"));
>>>> の所は、"Push"ではなく"push"が正しいようです。
>>> の件ですが、
>>> [openrtm-users 00849] Re: SimpleIO の run.sh
>>> のエラー
>>> のコードによると"Push"となっているので"Push"のままにいたしました。
>>> ただし、
>>> rtm\InPortBase.cpp(180):
>>> coil::normalize(dflow_type);
>>> rtm\InPortBase.cpp(240):
>>> coil::normalize(dflow_type);
>>> rtm\OutPortBase.cpp(379):
>>> coil::normalize(dflow_type);
>>> rtm\OutPortBase.cpp(438):
>>> coil::normalize(dflow_type);
>>> によりdataflow_typeプロパティは大文字、小文字が混在しても
>>> 特に問題がなさそうな気がします。
>>> ちなみに今回は"push"に変更して実行いたしました。
>>> 以上です。
>>> よろしくお願いします。
>>>
>>> Masayuki Shimizu wrote 2009/07/29 12:51:
>>>> 俵様
>>>>
>>>> 静岡大 清水です。
>>>>
>>>> 少し気になったのでコメントです。
>>>>
>>>> OutPortにwriteする前にポートが希望通り
>>>> 接続されていることを確認してますでしょうか。
>>>>
>>>> ポート接続の確認は、少々面倒なのですが、
>>>> PortService::get_connector_profiles()
>>>> でConnectorProfileを全て取得し、
>>>> 各プロファイルごとに、
>>>> ConnectorProfile::ports
>>>> を調べて希望通りの接続となっているかを
>>>> 確かめればできます。
>>>>
>>>> それと、接続プログラムの、
>>>> CORBA_SeqUtil::push_back(cprof.properties,
>>>> NVUtil::newNV("dataport.dataflow_type",
>>>> "Push"));
>>>> の所は、"Push"ではなく"push"が正しいようです。
>>>>
>>>> 清水
>>>>
>>>> --- 俵　崇文＠AIST
>>> wrote:
>>>>> 安藤様
>>>>> 俵です。
>>>>>
>>>>> 返信ありがとうございます。
>>>>>
>>>>>> 要は、自作のプログラムからポートの接続をすると、
>>>>>> OutPortからInPortへデータがいかないということでよろしいでしょうか？
>>>>> はい。
>>>>>
>>>>>
>>> 「OutPortに値が格納できない」というのがどういう現象を指しているのですか。
>>>>> 具体的にはVirtualRobotRTCが持つ
>>>>> RTC::OutPort インスタンス
>>>>>
>>> からRTC::OutPort::write()の実行を
>>>>> デバッガで追ったところrtm/OutPort.hの170行目
>>>>> virtual bool write(DataType& value)
>>>>> {
>>>>> if (m_OnWrite != NULL)
>>>>> {
>>>>> (*m_OnWrite)(value);
>>>>> }
>>>>> // check number of connectors
>>>>> size_t conn_size(m_connectors.size());
>>>>> if (!(conn_size > 0)) { return true; }
>>>>>
>>>>> で戻ってしまう現象です。
>>>>>
>>> SimpleIOだと同様にデバッグで追ってもそのまま戻らず実行されたので、
>>>>> m_connectorsのサイズが０によることが原因で
>>>>>
>>> バッファに値が書き込まれていないと判断いたしました。
>>>>>
>>> これらのポートをRTSystemEditorで接続するとどうなりますか？
>>>>> 手動で接続することはできましたが、
>>>>>
>>> その後続行すると自動接続時と同様の動作になりました。
>>>>> 以上です。よろしくお願いします。
>>>>>
>>>>> Ando Noriaki wrote 2009/07/29 9:49:
>>>>>> 俵様
>>>>>>
>>>>>> 安藤です
>>>>>>
>>>>>> 要は、自作のプログラムからポートの接続をすると、
>>>>>> OutPortからInPortへデータがいかないということでよろしいでしょうか？
>>> 「OutPortに値が格納できない」というのがどういう現象を指しているのですか。
>>> これらのポートをRTSystemEditorで接続するとどうなりますか？
>>>>>> 2009/07/28 15:40 に
>>>>> 俵　崇文＠AIST
>>>>> さんは書きました:
>>>>>>> 安藤様
>>>>>>> 俵です。
>>>>>>>
>>>>>>> 返信送れて申し訳ありません。
>>>>>>> その後試行錯誤してみたのですが、
>>>>>>> 結局狙い通りの動作がえられませんでした。
>>>>>>> また問題点を整理するための時間が必要でした。
>>>>>>> 改めて質問させてください。
>>>>>>>
>>>>>>>
>>> 外部プロセスとコアロジックRTC(図ではSampleSV)の仲介を
>>>> 行なう
>>> ControllerBridgeをOpenRTM0.4.2からOpenRTM1.0.0に
>>> 対応する過程でOutPortのバッファに値が格納できない現象
>>>> に対処したいので
>>>>>>> ご教示ください。
>>>>>>>
>>>>>>> torque
>>>>>>> ┌←───────←┐
>>>>>>> ┌──□──┐ ┌──□──┐
>>>>>>> │ Virtual │steer │ SampleSV │
>>>>>>> │ □→─→□ │
>>>>>>> │ Robot │ │ │
>>>>>>> │ □→─→□ │
>>>>>>> │ RTC │ vel │ RTC │
>>>>>>> └─────┘ └─────┘
>>>>>>> □:ポート
>>>>>>> ControlllerBridgeの動作例
>>>>>>>
>>>>>>> 添付したファイルは上図のRTC構築時のログです。
>>>>>>>
>> 実行例ではControlllerBridgeはSampleSVRTCとVirtualRobotRTCを
>> 生成して対応するポートを接続します。図ではVirtualRobotRTC側の
>>>>>>> steer OutPort、vel
>>>>> OutPortに値が格納できませんでした。
>>>>>>> 特にポート接続ではOpenRTMのサンプルSimpleIOの
>>>>>>>
>>> ConnectorComp.cppを参考にして以下のコードを作成しました。
>>>>>>> bool Controller_impl::connectPorts(Port_Service_Ptr_Type outPort,
>>>>>>>
>>>>> Port_Service_Ptr_Type inPort)
>>>>>>> {
>>>>>>> // connect ports
>>>>>>> RTC::ConnectorProfile cprof;
>>>>>>> cprof.connector_id = "";
>>>>>>> cprof.name =
>>> CORBA::string_dup("connector0");
>>>>>>> cprof.ports.length(2);
>>>>>>> cprof.ports[0] =
>>>>> Port_Service_Type::_duplicate(inPort);
>>>>>>> cprof.ports[1] =
>>>>> Port_Service_Type::_duplicate(outPort);
>>>>>>> #ifdef OPENRTM_VERSION_042
>>>>>>> CORBA_SeqUtil::push_back(cprof.properties,
>>>>>>>
>>>>> NVUtil::newNV("dataport.interface_type",
>>>>>>> "CORBA_Any"));
>>>>>>> CORBA_SeqUtil::push_back(cprof.properties,
>>>>>>>
>>>>> NVUtil::newNV("dataport.dataflow_type",
>>>>>>> "Push"));
>>>>>>> CORBA_SeqUtil::push_back(cprof.properties,
>>>>>>>
>>>>> NVUtil::newNV("dataport.subscription_type",
>>>>>>> "Flush"));
>>>>>>> #else
>>>>>>> CORBA_SeqUtil::push_back(cprof.properties,
>>>>>>>
>>>>> NVUtil::newNV("dataport.interface_type",
>>>>>>> "corba_cdr"));
>>>>>>> CORBA_SeqUtil::push_back(cprof.properties,
>>>>>>>
>>>>> NVUtil::newNV("dataport.dataflow_type",
>>>>>>> "Push"));
>>>>>>> CORBA_SeqUtil::push_back(cprof.properties,
>>>>>>>
>>>>> NVUtil::newNV("dataport.subscription_type",
>>>>>>> "flush"));
>>>>>>> #endif
>>>>>>> RTC::ReturnCode_t result =
>>>>> inPort->connect(cprof);
>>>>>>> return (result == RTC::RTC_OK);
>>>>>>> }
>>>>>>>
>>>>>>>
>>> サンプルConnectorCompとControlllerBridgeの主な相違点は、
>>>>>>> 1)SimpleIOでは異なるプロセスで別々のRTCを生成、
>>>>>>> 接続もConnectorCompプロセスで行なっているが、
>>>>>>>
>>> ControlllerBridgeでは同じプロセスで２つのRTCを生成し、
>>>>>>> ポート間を接続して値を授受している。
>>>>>>> 2)接続数が複数であること
>>>>>>> 3)RTCにInPortとOutPortが混在すること
>>>>>>>
>>> です。0.4.2を利用した場合は問題なく動作していました。
>>> ちなみにRTSystemEditorで動作を追った場合、各RTCの登録
>>>> 、
>>>>>>> ポート間接続時のライン描画を確認しました。
>>>>>>> 以上です。
>>>>>>> よろしくお願いいたします。
>>>>>>>
>>>>>>> Ando Noriaki wrote 2009/07/24 10:38:
>>>>>>>> 俵様
>>>>>>>>
>>>>>>>> 安藤です
>>>>>>>>
>>>>>>>> お世話になっております。
>>>>>>>>
>>>>>>>>
>>> 申し訳ございませんが、下記のメールはご質問でしょうか？
>>>>>>>> 意図がよくつかめませんでした。
>>>>>>>>
>>>>>>>> 2009/07/24 10:11 に
>>>>> 俵　崇文＠AIST
>>>>> さんは書きました:
>>>>>>>>> 安藤様
>>>>>>>>>
>>>>>>>>> 俵です。
>>>>>>>>>
>>>>>>>>> 早速の返信ありがとうございます。
>>>>>>>>>
>>>>>>>>>
>>> 仕様変更により接続するまでバッファが無い旨了解いたしました。
>>> 1)RTC::PortBase::connectの戻り値がtrueである。
>>> 2)RTCSystemEditorでは動作確認時に接続ラインが描画表示される。
>>> 3)ログにはnotify_connect()以下の接続の処理が記録されている
>>> 等の理由により接続は成功していると当方では判断していました。
>>>>>>>>> ログからは読み取れませんでしたが、
>>>>>>>>>
>>>>> 未接続の段階でwriteメンバを呼び出してしまっているというご指摘については調査してみます。
>>>>>>>>>
>>>>>>>>> 以上です。
>>>>>>>>> よろしくお願いいたします。
>>>>>>>>>
>>>>>>>>> Ando Noriaki wrote 2009/07/23 14:05:
>>>>>>>>>> 俵さま
>>>>>>>>>>
>>>>>>>>>> 安藤です
>>>>>>>>>>
>>>>>>>>>>
>>> 1.0からは、バッファはコネクタに属する構造に変更されました。
>>>>
>> したがって、接続するまではバッファが存在せずOutPortにwrite しても値はどこにも格納されません。
>>>>>>>>>>
>>> このような仕様で不都合が生じるようでしたら、どのようなケースで
>>> 問題になるのか利用例を教えていただけますでしょうか。
>>>>>>>>>> よろしくお願いいたします。
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2009/07/23 13:52 に 俵　崇文＠AIST さんは書きました:
>>>>>>>>>>> 産総研 知能システム研究部門
>>>>> ヒューマノイド研究グループ
>>>>>>>>>>> にてお世話になっております 俵です。
>>>>>>>>>>>
>>>>>>>>>>>
>>> 現在OpenHRP3.1.0β2ベースで可能であればOpenRTM0.4.2への
>>> 互換性を保ったままOpenRTM1.0.0-RC1への対応をしております。
>>>>>>>>>>> OpenRTM1.0.0-RC1に対応した場合、
>>>>>>>>>>> bool OutPort::write(DataType& value)
>>>>>>>>>>> の処理中m_connectorsのサイズが0による理由で
>>>>>>>>>>>
>>> バッファに値を格納できない現象に遭遇しております。
>>> 初期化方法に問題があると疑って動作を追っているのですが、
>>>>>>>>>>> ログなどによると
>>>>>>>>>>> Jul 23 10:56:41 PARANOID: steer: connector
>>>>> push backed: 1
>>>>>>>>>>> Jul 23 10:56:41 DEBUG: steer:
>>>>> publishInterface() successfully finished.
>>>>>>>>>>> Jul 23 10:56:41 PARANOID: steer: 0
>>> connectors
>>>>> are existing
>>>>>
>>> と一見m_connectorsコンテナにコネクタインスタンスが格納されるているようです。
>>>>>>>>>>>
>>>>>>>>>>>
>>>>> このような場合の対処方法についてご教示ください。
>>>>>>>>>>> 動作時のログも添付いたします。
>>>>>>>>>>> よろしくお願いします。
>>>>>>>>>>>
>>>> Print RTC::PortService_var info
>>> _PD_repoId: IDL:omg.org/CORBA/Object:1.0
>>> ConnectorProfileList[0]
>>> name: connector0
>>> connector_id: 67ca269d-5737-4437-8580-9dc69725892d
>>> properties:
>>> dataport.interface_type: corba_cdr
>>> dataport.dataflow_type: push
>>> dataport.subscription_type: flush
>>> dataport.corba_cdr.inport_ior:
>>>
>> IOR:010000001a00000049444c3a4f70656e52544d2f496e506f72744364723a312e30000000010000000000000064000
>> 000010102000d0000003139322e3136382e36352e310000060e0e000000fe6844714a00000a8c000000000e00000200000000000000080000000100000000545
>> 441010000001c00000001000000010001000100000001000105090101000100000009010100
>>> dataport.corba_cdr.inport_ref: not a string value
>>>
>>> ports[0]
>>> in()->_is_nil(): false
>>> inout()->_is_nil(): false
>>> out()->_is_nil(): true
>>> ports[1]
>>> in()->_is_nil(): false
>>> inout()->_is_nil(): false
>>> out()->_is_nil(): true
>>>
>>>
>>> Print RTC::PortService_var info
>>> _PD_repoId: IDL:omg.org/CORBA/Object:1.0
>>> ConnectorProfileList[0]
>>> name: connector0
>>> connector_id: 6f1fefad-d13d-460b-87e1-81592e104ae7
>>> properties:
>>> dataport.interface_type: corba_cdr
>>> dataport.dataflow_type: push
>>> dataport.subscription_type: flush
>>> dataport.corba_cdr.inport_ior:
>>>
>> IOR:010000001a00000049444c3a4f70656e52544d2f496e506f72744364723a312e30000000010000000000000064000
>> 000010102000d0000003139322e3136382e36352e310000060e0e000000fe6844714a00000a8c000000000f00000200000000000000080000000100000000545
>> 441010000001c00000001000000010001000100000001000105090101000100000009010100
>>> dataport.corba_cdr.inport_ref: not a string value
>>>
>>> ports[0]
>>> in()->_is_nil(): false
>>> inout()->_is_nil(): false
>>> out()->_is_nil(): true
>>> ports[1]
>>> in()->_is_nil(): false
>>> inout()->_is_nil(): false
>>> out()->_is_nil(): true
>>>> void consoleOutPortRefInfo(PortService_ptr portRef)
>>> {
>>>
>>> if(portRef->_is_nil() ){
>>> std::cout << "portRef is nill" << std::endl;
>>> } else {
>>> std::cout << "Print RTC::PortService_var
>>> info" << std::endl;
>>> std::string spcStr(" ");
>>> std::cout << "_PD_repoId: " <<
>>> portRef->_PD_repoId << std::endl;
>>> ConnectorProfileList_var profileList =
>>> portRef->get_connector_profiles();
>>> for(_CORBA_ULong i = _CORBA_ULong(0); i <
>>> profileList->length(); ++i){
>>> ConnectorProfile& localConPro =
>>> profileList[i];
>>> std::cout << "ConnectorProfileList[" <<
>>> i << "]" << std::endl;
>>> std::cout << spcStr << "name: " <<
>>> localConPro.name << std::endl;
>>> std::cout << spcStr << "connector_id: "
>>> << localConPro.connector_id << std::endl;
>>>
>>> std::cout << spcStr << "properties: " <<
>>> std::endl;
>>> std::cout <<
>>> ::NVUtil::toString(localConPro.properties) <<
>>> std::endl;
>>>
>>> PortServiceList& portServiceList =
>>> localConPro.ports;
>>> for(_CORBA_ULong h = _CORBA_ULong(0); h
>>> < portServiceList.length(); ++h){
>>> std::string spcStr2 = spcStr;
>>> spcStr2 += spcStr;
>>> std::cout << spcStr << "ports[" << h
>>> << "]" << std::endl;
>>> std::cout << spcStr2 <<
>>> "in()->_is_nil(): " <<
>>>
>>> (portServiceList[h].in()->_is_nil() ? "true" :
>>> "false" ) << std::endl;
>>> std::cout << spcStr2 <<
>>> "inout()->_is_nil(): " <<
>>>
>>> (portServiceList[h].inout()->_is_nil() ? "true" :
>>> "false" ) << std::endl;
>>> std::cout << spcStr2 <<
>>> "out()->_is_nil(): " <<
>>>
>>> (portServiceList[h].out()->_is_nil() ? "true" :
>>> "false" ) << std::endl;
>>> }
>>> }
>>> }
>>> }