[openrtm-users 01227] Re: rtc_handle for OpenrtM-aist-1.0.0

[ts]

安藤様，皆様，

末廣です．
前の例では，ポート名がユニークであっても
今の形ではポートをちゃんと使える形で区別できない
という例を挙げました．

今回は逆に無駄にユニークであるために不便な例を挙げます．
「無駄に」というのは，本来コンポーネント内でユニークであれば
良いのに，複数のコンポーネントにまたがってユニークにしよう
としている点です．

私は，ロボットアームの制御プログラムをRTC化していますが，
そこでは，ロボットアームRTCがvelという名前の関節角速度
指令値を受け取るポートを持っていれば入れ替えて使うことが
できるようになっています．
それがXXX.velとなるとそれを操作するプログラムが非常に
書きにくくなります．

もちろんXXX.を削るプログラムが書けないわけではないのですが
おかしくありませんか？
個々のRTCはそれぞれの名前空間を持つべきです．
それに対して，ツール側ででXXX.velとしてアクセスするような
シンタックスシュガーをサポートするのは構いませんが
RTC内部での名前はvelのままであるのが普通ではないでしょうか．

仕様を作成したご本人を前にしてなんなのですが，，，
Semantics
(1) Ports owned by an RTC are distinguished by their names.
(2) Therefore, this name should be unique within the target RTC.

(1)を満たすために(2)でなくてはいけないと言っているのに，
今のやり方は(2)は満たしているが(1)を満たしていないという
抜け殻状態になっていませんか？

ご検討よろしくお願いします．

(10/05/18 12:38), ts wrote:
> 安藤様，
> 
> 末廣です．
> 
> たとえば，現在値と目標値を受けて制御を行うコンポーネントを
> 考えましょう．そのコンポーネントの入力ポートを，
> th_cur, th_refとか呼びたいわけです．
> 
> それぞれの入力に平滑化のフィルタを入れるために，
> inとoutをもつフィルタコンポーネントを使って
> 複合コンポーネント化したとします．
> 
> するとそのポート名は，
> comp0.inとcomp1.inになるのだと思うのですが
> そのどちらがth_curでどちらがth_refなのでしょうか？
> その情報はどこに保持されているのでしょうか？
> 
> ちゃんとth_cur, th_refという名前をつけましょうというのが，
> 以下のOMG仕様の意図していることだと思うのですが違いますか？
> 
>> ・ポート名は（OMG RTCの仕様上は）同一RTC内で一意でなければならない
>>   formal/08-04-04 p.65
>>   Semantics
>>   Ports owned by an RTC are distinguished by their names.
>>   Therefore, this name should be unique within the target RTC.
>> 　とある。
> 
> 名前で区別できる（機能も含めて）というのは，そういうことなのでは？
> 
> 実装上の制約はあるのかもしれませんが，この辺は重要な議論だと思います．
> 
> ご検討よろしくお願いします．
> 
> 
> (10/05/18 9:37), Ando Noriaki wrote:
>> 末廣様
>>
>> 安藤です
>>
>>> (10/05/18 1:33), Ando Noriaki wrote:
>>>
>>>>> 私は，あるコンポーネントが複合コンポーネントか単独のコンポーネントかは
>>>>> 実装の問題と考えていました．
>>>>> すなわち，1つのコンポーネントの中で名前の衝突はないということです．
>>>>
>>>> すみません。実装の問題というのはどういう意味なのか教えていただけ
>>>> ますでしょうか？
>>>
>>> ポート名が現状のように，コンポート名.ポート名と名付けられる
>>> としても，複合コンポーネントの各ポートの名称は，
>>> 複合コンポーネント名.ポート名となるべきではないかということです．
>>>
>>> 内部コンポーネント名.ポート名では，複合コンポーネントの
>>> 内部構造が変わるたびにポート名が変わってしまいますよね．
>>> 困りませんか？
>>
>> 現在の仕様では、
>> ・ポート名は<もともとのownerRTC>.<ポート名>
>> ・ポート名は複合化されても変わらない（変更できない）
>> ・複合コンポーネントの親は、ポートのリファレンスを保持するだけで
>> 　実際の管理はもともとの親が行う
>>
>> となっていますので、上記の問題は起こりません。
>> ただし、複合コンポーネントのポートが子コンポーネント名.ポート名
>> となるのは、少々すっきりしないのもわかります。
>> 一方で、複合コンポーネントをどんなに階層化しても、
>> もともとそのポートが何のどういうポートであるか、名前から
>> ある程度分かるという利点もあります。
>>
>>> また今の仕様だと，コンポート名というのがコンポーネントの
>>> インスタンス名になっているのでインスタンスごとにポート名が
>>> 違うというのもやりにくくはないですか？
>>> こちらに関しては，プログラム的にはインスタンス名を削る
>>> だけですむのでまだよいのですが．
>>
>> 確かに、この仕様のために、実装が若干ややこしくなっているのは
>> 否めません。ただし、複合コンポーネントで、ポート名がぶつかるケース
>> に対処するうまい方法が思いつきませんでした。
>>
>> rtc_handleで仮に複合コンポーネントの作成、分解や、ポートの
>> 公開、非公開を制御するAPIを提供するとしたら、末廣さんなら
>> どのようにしますか？
>>
>> 前提として、以下の制約および可能性があります。
>>
>> ・ポート名は基本的には外部からは変更できない（内部からはできる）
>>  PortProfile は2つの方法で取得される
>>  1) RTObject::get_component_profile() から ComponentProfile::port_profiles
>>  2) PortService::get_port_profile() から PortProfile
>>  前者は複合RTCの親ですり替えることは可能だが、後者は難しいので
>> ・ポートのownerも基本的には外部から変更できない（変更されることはない）
>> ・ポート名は（OMG RTCの仕様上は）同一RTC内で一意でなければならない
>>   formal/08-04-04 p.65
>>   Semantics
>>   Ports owned by an RTC are distinguished by their names.
>>   Therefore, this name should be unique within the target RTC.
>> 　とある。
>>
>> これらの前提を考えると、現在の実装のようにポート名を最初から
>> できるだけ一意になるように付ける、というのが実装的にもシンプルで
>> ベターな選択であると私は考えています。
>>
>> 上記の制約の上で、ポート名を純粋にポート名だけとして、
>> かつ複合コンポーネント等にもうまく対処できる方法を思いついた方が
>> いらっしゃいましたら、教えていただけないでしょうか？
>>
>> ＃最終手段としてOMGでRTFを立ち上げて仕様を変えてしまう
>> ＃というのもありかもしれませんが。。。。
>>
>> ジェフさん
>>
>>> 安藤様
>>>
>>> ジェフです。
>>>
>>> rtctreeにとって、ポートはいつもコンポーネントかコネクタから取ります。コ
>>> ンポーネントの場合、もうどのコンポーネントからか分かるから問題ありませ
>>> ん。コネクタの場合、rtctreeは自動的にポートのownerを探して、その情報もも
>>> らいます。
>>
>> 了解です。ツールの方でうまく対処していただければと思います。
>> Pythonなら正規表現も簡単に使えますし。。。。
>>
>>
> 
> 


-- 
Takashi Suehiro, Professor, Intelligent Systems Lab,
Graduate School of Information Systems,
the University of Electro-Communications
Tel: +81-424-43-5655 Fax: +81-424-43-5682
E-mail: suehiro ＠ is.uec.ac.jp
1-5-1 Chofugaoka, Chofu, Tokyo 1828585, Japan