[openrtm-users 01052] python 版におけるSystemEditorを使用しないコンポーネントの接続方法について

4 posts / 0 new
Last post
root
Offline
Last seen: 1 day 12 hours ago
Joined: 2009-06-23 14:31
[openrtm-users 01052] python 版におけるSystemEditorを使用しないコンポーネントの接続方法について

本田技術研究所の鳥井です。

python版で、スクリプトからコンポーネントを配線する方法について質問がござい
ます。

SimpleIO ディレクトリに、入力ポートと出力ポートがあるコンポーネントとして
ConsoleProxy というコンポーネントを新規に作成しました。

さらに、ConsoleOut.pyの MyModuleInit()内で、インスタンスを
追加する一文( comp2 = manager.createComponent('ConsoleOut')
を加え、以下の用に配線したいと思います。

+---ConsoleOut0
|
CosoleIn0---ConsoleProxy---+---ConsoleOut1

さて、これを入出力ポートの組毎にConnectorProfileを作成し、
その度に関連するポートのconnect()を呼ぶことで、配線できることは確認しました
(合計3度connect()を呼ぶことになります)。

しかし、RTCの仕様によると、一度のconnectで、ConnectorProfileを
伝播させて、全ての配線ができるように読み取れましたので、

ポートリストに例えば、

[pin[0], pproxy[0], pproxy[1], pout[0], pout2[0]]

このようして、pin[0] のconnectを呼んでみたのですが、
最初の一組しか配線できませんでした。

なにか解釈を間違えているのでしょうか? どうぞご教示ください。

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

Undefined
root
Offline
Last seen: 1 day 12 hours ago
Joined: 2009-06-23 14:31
[openrtm-users 01055] python 版におけるSystemEditorを使用しないコンポーネントの接続

鳥居様

産総研 安藤です

お世話になっております。

> 本田技術研究所の鳥井です。
>
> python版で、スクリプトからコンポーネントを配線する方法について質問がござい
> ます。
>
> SimpleIO ディレクトリに、入力ポートと出力ポートがあるコンポーネントとして
> ConsoleProxy というコンポーネントを新規に作成しました。
>
> さらに、ConsoleOut.pyの MyModuleInit()内で、インスタンスを
> 追加する一文( comp2 = manager.createComponent('ConsoleOut')
> を加え、以下の用に配線したいと思います。
>
>
> +-(2)-ConsoleOut0
> |
> CosoleIn0-(1)-ConsoleProxy---+-(3)-ConsoleOut1
>
>
> さて、これを入出力ポートの組毎にConnectorProfileを作成し、
> その度に関連するポートのconnect()を呼ぶことで、配線できることは確認しました
> (合計3度connect()を呼ぶことになります)。
>
> しかし、RTCの仕様によると、一度のconnectで、ConnectorProfileを
> 伝播させて、全ての配線ができるように読み取れましたので、
>
> ポートリストに例えば、
>
> [pin[0], pproxy[0], pproxy[1], pout[0], pout2[0]]
>
> このようして、pin[0] のconnectを呼んでみたのですが、
> 最初の一組しか配線できませんでした。
>
> なにか解釈を間違えているのでしょうか? どうぞご教示ください。

おっしゃる通り、OMG RTC 仕様では、複数のポートが関連する
接続(Connector)を1回の呼び出しで構成できるような記述があります。

ここで注意する必要があるのが、ポートの接続と、ポートに付属する
インターフェースの接続とは別であるということです。
鳥居さんがされた後者の操作では、(1)の接続しか動作しなかったかも
しれませんが、すべてのポートは同一のConnectorProfileを共有しており、
「ポート的には」接続されている状態になっています。
一方、OMGのRTC仕様では、「インターフェースの接続」に関しては
触れられておらず、実装依存ということになっております。

現状のデータポートでは、ポートはInPort1対OutPort1であることが
前提となっており、鳥居さんがされたような接続方法は申し訳ありあせんが、
サポートされておりません。

基本的な考え方として、データポートはRTC間のデータストリームチャネル
であり、1(out)対n(in)またはn(out)対1(in)を一つのコネクタで構成するのは
いろいろと混乱を招きそうなためこういう仕様にしております。
また、1度のconnect()呼び出しで構成できるのは1つのコネクタですので、
仮にdisconnect()すると、上記の(1)〜(3)すべての接続が切断されてしまい
これもまた混乱のもとになると考えました。

また、上記の例では、考え方にもよりますが、(1) と (2),(3) の接続には
関連が無さそうにも見えますので、同じ接続(Connector)として構成するのは
少々違和感があります。
#(2)、(3)の接続を1回のconnect()呼び出しで構成するのは、僕としては
#ありかなとも思いますが。。。

また、インターフェースレベルで考えますと、1つのコネクタ内で、
インターフェース同士の接続関係を指定してあげる必要があるので
ConnectorProfileを作るのが少々面倒になります。

上の例で登場する4つのコンポーネントのインターフェースを
仮に、Provided I/Fを "o--"、Required I/F を "--<" と書けば

[ConsoleIn]--< (r0)
(p0) o--[ConsoleProxy]--< (r1)
(p1) o--[ConsoleOut0]
(p2) o--[ConsoleOut1]

のように書くことができます。
ここで、それぞれp0-2, r0-1 のように名前を付けておきます。

上の例のようの接続したい場合、それぞれインターフェースごとの
接続の対応関係は、
(r0)--(p0), (r1)--(p1), (r1')--(p2)
のようになりますが、これをConnectorProfileに与えてあげ、
かつ各ポートでは、この記述に従ってインターフェースごとの
接続を構成してあげる必要があります。

さらに、(r1)と(r1')のように、Requiredインターフェースは通常
複数のProvidedインターフェースにはつながりませんので、
上記の接続を行うにはr1を複数用意する必要があります。
データポートでは接続毎に動的にRequiredインターフェースを
増やすことでこれに対処しております。

実は、間もなくリリースする1.0では、サービスポートに限り、
上記のような複雑なインターフェースの接続関係を接続時に
指定する方法がサポートされます。
しかし、データポートでは上記の理由により、このような複雑な
指定に対応させるメリットがあまり無いように思えましたので、
1対1接続のみサポートする仕様のままです。

ご理解いただけましたでしょうか?

root
Offline
Last seen: 1 day 12 hours ago
Joined: 2009-06-23 14:31
[openrtm-users 01058] python 版におけるSystemEditorを使用しないコンポーネントの接続

鳥井@本田技術研究所です。

安藤様

丁寧な解説をありがとうございました。

ポートの接続と、ポートに付随するインターフェイスの接続が
別であるとの由、
(ポートのインターフェイスとしては接続されていなくても)
ポートとしては接続できているという状態に、
なにか機能的に必要性があるということでしょうか?

また、現実装では一対のポート接続のみサポートの由、
了解しました。確かにデータポートに関しては、ポート対毎に
connectしたほうが混乱が少ないようにも思います。

> 鳥居様
>
> 産総研 安藤です
>
> お世話になっております。
>
> > 本田技術研究所の鳥井です。
> >
> > python版で、スクリプトからコンポーネントを配線する方法について質問がござい
> > ます。
> >
> > SimpleIO ディレクトリに、入力ポートと出力ポートがあるコンポーネントとして
> > ConsoleProxy というコンポーネントを新規に作成しました。
> >
> > さらに、ConsoleOut.pyの MyModuleInit()内で、インスタンスを
> > 追加する一文( comp2 = manager.createComponent('ConsoleOut')
> > を加え、以下の用に配線したいと思います。
> >
> >
> > +-(2)-ConsoleOut0
> > |
> > CosoleIn0-(1)-ConsoleProxy---+-(3)-ConsoleOut1
> >
> >
> > さて、これを入出力ポートの組毎にConnectorProfileを作成し、
> > その度に関連するポートのconnect()を呼ぶことで、配線できることは確認しました
> > (合計3度connect()を呼ぶことになります)。
> >
> > しかし、RTCの仕様によると、一度のconnectで、ConnectorProfileを
> > 伝播させて、全ての配線ができるように読み取れましたので、
> >
> > ポートリストに例えば、
> >
> > [pin[0], pproxy[0], pproxy[1], pout[0], pout2[0]]
> >
> > このようして、pin[0] のconnectを呼んでみたのですが、
> > 最初の一組しか配線できませんでした。
> >
> > なにか解釈を間違えているのでしょうか? どうぞご教示ください。
>
> おっしゃる通り、OMG RTC 仕様では、複数のポートが関連する
> 接続(Connector)を1回の呼び出しで構成できるような記述があります。
>
> ここで注意する必要があるのが、ポートの接続と、ポートに付属する
> インターフェースの接続とは別であるということです。
> 鳥居さんがされた後者の操作では、(1)の接続しか動作しなかったかも
> しれませんが、すべてのポートは同一のConnectorProfileを共有しており、
> 「ポート的には」接続されている状態になっています。
> 一方、OMGのRTC仕様では、「インターフェースの接続」に関しては
> 触れられておらず、実装依存ということになっております。
>
> 現状のデータポートでは、ポートはInPort1対OutPort1であることが
> 前提となっており、鳥居さんがされたような接続方法は申し訳ありあせんが、
> サポートされておりません。
>
> 基本的な考え方として、データポートはRTC間のデータストリームチャネル
> であり、1(out)対n(in)またはn(out)対1(in)を一つのコネクタで構成するのは
> いろいろと混乱を招きそうなためこういう仕様にしております。
> また、1度のconnect()呼び出しで構成できるのは1つのコネクタですので、
> 仮にdisconnect()すると、上記の(1)〜(3)すべての接続が切断されてしまい
> これもまた混乱のもとになると考えました。
>
> また、上記の例では、考え方にもよりますが、(1) と (2),(3) の接続には
> 関連が無さそうにも見えますので、同じ接続(Connector)として構成するのは
> 少々違和感があります。
> #(2)、(3)の接続を1回のconnect()呼び出しで構成するのは、僕としては
> #ありかなとも思いますが。。。
>
>
> また、インターフェースレベルで考えますと、1つのコネクタ内で、
> インターフェース同士の接続関係を指定してあげる必要があるので
> ConnectorProfileを作るのが少々面倒になります。
>
> 上の例で登場する4つのコンポーネントのインターフェースを
> 仮に、Provided I/Fを "o--"、Required I/F を "--<" と書けば
>
> [ConsoleIn]--< (r0)
> (p0) o--[ConsoleProxy]--< (r1)
> (p1) o--[ConsoleOut0]
> (p2) o--[ConsoleOut1]
>
> のように書くことができます。
> ここで、それぞれp0-2, r0-1 のように名前を付けておきます。
>
> 上の例のようの接続したい場合、それぞれインターフェースごとの
> 接続の対応関係は、
> (r0)--(p0), (r1)--(p1), (r1')--(p2)
> のようになりますが、これをConnectorProfileに与えてあげ、
> かつ各ポートでは、この記述に従ってインターフェースごとの
> 接続を構成してあげる必要があります。
>
> さらに、(r1)と(r1')のように、Requiredインターフェースは通常
> 複数のProvidedインターフェースにはつながりませんので、
> 上記の接続を行うにはr1を複数用意する必要があります。
> データポートでは接続毎に動的にRequiredインターフェースを
> 増やすことでこれに対処しております。
>
> 実は、間もなくリリースする1.0では、サービスポートに限り、
> 上記のような複雑なインターフェースの接続関係を接続時に
> 指定する方法がサポートされます。
> しかし、データポートでは上記の理由により、このような複雑な
> 指定に対応させるメリットがあまり無いように思えましたので、
> 1対1接続のみサポートする仕様のままです。
>
> ご理解いただけましたでしょうか?

root
Offline
Last seen: 1 day 12 hours ago
Joined: 2009-06-23 14:31
[openrtm-users 01059] python 版におけるSystemEditorを使用しないコンポーネントの接続

鳥居様

安藤です

> 鳥井@本田技術研究所です。
>
> 安藤様
>
> 丁寧な解説をありがとうございました。
>
> ポートの接続と、ポートに付随するインターフェイスの接続が
> 別であるとの由、
> (ポートのインターフェイスとしては接続されていなくても)
> ポートとしては接続できているという状態に、
> なにか機能的に必要性があるということでしょうか?

OMG RTCの仕様では、インターフェースの接続が失敗した場合
Portの接続がどうなるかについては記述していなかったように思います。
ですので、これについても実装依存ということになるかと思います。
以下はOpenRTMではどうなっているかという話です。

データポートについては、n対n接続は想定外の接続なので
ある意味チェックをさぼっているだけということになります。
少々古いですが、接続処理の仕様は以下のようになっています。
http://www.is.aist.go.jp/rt/OpenRTM-aist/doxygen/ClassReference/classRTC_1_1DataOutPort.html

サービスポートに関しては、現状のインターフェースの接続条件は
・インターフェースの「型名」と「インスタンス名」が一致すること。
という、少々厳しい制約になっているため、接続時にすべての
Required・Providedインターフェースがつながらなくても、
特に接続エラーとしない、ということにしております。
http://www.is.aist.go.jp/rt/OpenRTM-aist/doxygen/ClassReference/classRTC_1_1CorbaPort.html#d9a122cbe2f9892cc9555e805571742e

たとえば、仮に今いま
・カメラコントローラ
・パンチルトカメラ
という2つのコンポーネントがありこれらはそれぞれ1つのポートに
以下のインターフェースを持っているものとします。

・カメラコントローラ
 カメラコントロール --<
・パンチルトカメラ
 カメラコントロール --o
 パンチルトコントロール --o

カメラコントローラRTCはパンチルトのインターフェースを
持っていませんが、カメラコントロールインターフェースは
持っているので、これだけを接続してシステムを構築する
というのも、あり得ない話ではないと思います。
そうすると、パンチルトコントロールがつながらないからといって
接続を拒否するのは少々厳密すぎます。

いずれにしろ、上記の「型名」と「インスタンス名」の一致という
制約は、あまりに厳しすぎるので、次のリリース版では、
どのインターフェースをどのインターフェースとつなぐかを全てConnectorProfileで
指定できるようにもなりますし、未接続インターフェースが存在する
場合に接続がエラーとなるようなフラグもConnectorProfileで
与えることができるようになる予定です。

そもそも、ポートはPortInterfaceProfileとして、インターフェース
情報を公開しているので、接続できるかどうかを判断して
適切なConnectorProfileを設定するのは、ある意味connect()を
呼ぶツールの責任であるとも考えられます。
#この辺はOMG RTC仕様では何も述べてませんが。。。

現在、uITRON版のOpenRTM-aistも開発されており、
その際には、非力なCPUが使われることもありますので、
RTC側の処理はできるだけ軽くする必要があります。
その場合、ツール側にある程度責任を負ってもらうというのも
一つの考え方であると私は考えております。

> また、現実装では一対のポート接続のみサポートの由、
> 了解しました。確かにデータポートに関しては、ポート対毎に
> connectしたほうが混乱が少ないようにも思います。
>
>
> noriaki.ando@gmail.com wrote on 2009/12/25 11:28:47:
>
>> 鳥居様
>
>> 産総研 安藤です
>
>> お世話になっております。
>
>> > 本田技術研究所の鳥井です。
>> >
>> > python版で、スクリプトからコンポーネントを配線する方法について質問がござい
>> > ます。
>> >
>> > SimpleIO ディレクトリに、入力ポートと出力ポートがあるコンポーネントとして
>> > ConsoleProxy というコンポーネントを新規に作成しました。
>> >
>> > さらに、ConsoleOut.pyの MyModuleInit()内で、インスタンスを
>> > 追加する一文( comp2 = manager.createComponent('ConsoleOut')
>> > を加え、以下の用に配線したいと思います。
>> >
>> >
>> > +-(2)-ConsoleOut0
>> > |
>> > CosoleIn0-(1)-ConsoleProxy---+-(3)-ConsoleOut1
>> >
>> >
>> > さて、これを入出力ポートの組毎にConnectorProfileを作成し、
>> > その度に関連するポートのconnect()を呼ぶことで、配線できることは確認しました
>> > (合計3度connect()を呼ぶことになります)。
>> >
>> > しかし、RTCの仕様によると、一度のconnectで、ConnectorProfileを
>> > 伝播させて、全ての配線ができるように読み取れましたので、
>> >
>> > ポートリストに例えば、
>> >
>> > [pin[0], pproxy[0], pproxy[1], pout[0], pout2[0]]
>> >
>> > このようして、pin[0] のconnectを呼んでみたのですが、
>> > 最初の一組しか配線できませんでした。
>> >
>> > なにか解釈を間違えているのでしょうか? どうぞご教示ください。
>
>> おっしゃる通り、OMG RTC 仕様では、複数のポートが関連する
>> 接続(Connector)を1回の呼び出しで構成できるような記述があります。
>
>> ここで注意する必要があるのが、ポートの接続と、ポートに付属する
>> インターフェースの接続とは別であるということです。
>> 鳥居さんがされた後者の操作では、(1)の接続しか動作しなかったかも
>> しれませんが、すべてのポートは同一のConnectorProfileを共有しており、
>> 「ポート的には」接続されている状態になっています。
>> 一方、OMGのRTC仕様では、「インターフェースの接続」に関しては
>> 触れられておらず、実装依存ということになっております。
>
>> 現状のデータポートでは、ポートはInPort1対OutPort1であることが
>> 前提となっており、鳥居さんがされたような接続方法は申し訳ありあせんが、
>> サポートされておりません。
>
>> 基本的な考え方として、データポートはRTC間のデータストリームチャネル
>> であり、1(out)対n(in)またはn(out)対1(in)を一つのコネクタで構成するのは
>> いろいろと混乱を招きそうなためこういう仕様にしております。
>> また、1度のconnect()呼び出しで構成できるのは1つのコネクタですので、
>> 仮にdisconnect()すると、上記の(1)〜(3)すべての接続が切断されてしまい
>> これもまた混乱のもとになると考えました。
>
>> また、上記の例では、考え方にもよりますが、(1) と (2),(3) の接続には
>> 関連が無さそうにも見えますので、同じ接続(Connector)として構成するのは
>> 少々違和感があります。
>> #(2)、(3)の接続を1回のconnect()呼び出しで構成するのは、僕としては
>> #ありかなとも思いますが。。。
>
>>
>> また、インターフェースレベルで考えますと、1つのコネクタ内で、
>> インターフェース同士の接続関係を指定してあげる必要があるので
>> ConnectorProfileを作るのが少々面倒になります。
>
>> 上の例で登場する4つのコンポーネントのインターフェースを
>> 仮に、Provided I/Fを "o--"、Required I/F を "--<" と書けば
>
>> [ConsoleIn]--< (r0)
>> (p0) o--[ConsoleProxy]--< (r1)
>> (p1) o--[ConsoleOut0]
>> (p2) o--[ConsoleOut1]
>
>> のように書くことができます。
>> ここで、それぞれp0-2, r0-1 のように名前を付けておきます。
>
>> 上の例のようの接続したい場合、それぞれインターフェースごとの
>> 接続の対応関係は、
>> (r0)--(p0), (r1)--(p1), (r1')--(p2)
>> のようになりますが、これをConnectorProfileに与えてあげ、
>> かつ各ポートでは、この記述に従ってインターフェースごとの
>> 接続を構成してあげる必要があります。
>
>> さらに、(r1)と(r1')のように、Requiredインターフェースは通常
>> 複数のProvidedインターフェースにはつながりませんので、
>> 上記の接続を行うにはr1を複数用意する必要があります。
>> データポートでは接続毎に動的にRequiredインターフェースを
>> 増やすことでこれに対処しております。
>
>> 実は、間もなくリリースする1.0では、サービスポートに限り、
>> 上記のような複雑なインターフェースの接続関係を接続時に
>> 指定する方法がサポートされます。
>> しかし、データポートでは上記の理由により、このような複雑な
>> 指定に対応させるメリットがあまり無いように思えましたので、
>> 1対1接続のみサポートする仕様のままです。
>
>> ご理解いただけましたでしょうか?

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