[openrtm-users 01520] SI2010でのRTミドルウエアに関する質疑応答

5 個の投稿 / 0 new
最終投稿
root
オフライン
Last seen: 3時間 35分 前
登録日: 2009-06-23 14:31
[openrtm-users 01520] SI2010でのRTミドルウエアに関する質疑応答

OpenRTM-aistメーリングリストの皆様

お世話になっております。
産総研 栗原です。

先日開催されましたSI2010での「RTミドルウエアコンテスト2010」にてご質問またはコメ
ント頂きました内容について、遅くなりましたが、回答させて頂きます。

なお、本メールは、SI2010に参加されなかった方にも情報を共有していただければと思い
、この ML に流させて頂いております。

Q1. onInitialize/onFinalizeでデバイスのオープン処理やメモリ領域の確保/破棄を
  行うのではなく、onActivated/onDeactivatedで行った方がよいのでは?

A1. ・そのRTCにて、デバイスを独占したい場合などは、onInitializeの段階にてデバイ
   スデバイスのオープンを行った方がよい。
  ・RAII(Resource Acquisition Is Initialization)イディオムをRTCにあてはめると
onInitialize/onFinalizeに相当するのでは。
  ・RTCで扱うデバイスや、目的によりonInitializeにするか、onActivatedにするか
   判断する必要がある。

Q2. OpenRTM-aist-1.0.0ではバッファリングポリシーが導入されており、データが読み込
  み可能かを確認するためにはread() の戻り値を確認すればよいので、isNew()は必要
  ないのでは?
A2. ・バッファが空の状態でもブロックしないようにバッファリングポリシーが正しく設
   定されていればread()での確認でもよい。
  ・バッファが空の状態で、データが読み込み可能かを確認するためには、read()より
   isNew()の方が処理が単純で早い。
・read()では、push接続においてInPortに届いたデータが最新かどうかの判断はでき
ない。

Q3. 開発者は、push型で接続するのを想定して作成されたが、ユーザーがpull型で接続さ
  れるといった懸念事項がある。これを制限するにはどうすればよいのか?
A3. ・component.confなどのコンフィグレーションファイルにてdataflow_typeを指定
   して、これを接続時に反映できるように検討させて頂きます。

Q4. デベロッパーズガイドを早く完成させてほしい。
A4. 現在、執筆中ですので、もうしばらくお待ち下さい。

何かコメント等ございましたら、ご遠慮なく頂ければと存じます。
以上、宜しくお願い致します。

未定義
root
オフライン
Last seen: 3時間 35分 前
登録日: 2009-06-23 14:31
[openrtm-users 01521] SI2010でのRTミドルウエアに関する質疑応答

リバストの菅です.
お世話になっております.

>栗原様:
ご苦労様です.

Q1に対してです.
結構,どうでもいいと思っている部分もありますが,
その半面,大事な問題を含んでいると思っています.
ある程度,「こうして作ってください」というポリシーがあると,
分かりやすい,と思う人が多い,と考えています.

現状では,このメーリングリストに登録している人も,
アーリーアダプターの人ばかりでしょうが,
他の人にも使ってもらうのであれば,
プログラミングの基準を作るべきだし,
そういうのが公式にあった方がやりやすいという人が,
特に日本人には多い気がします・・・

さて,onActivatedかonInitializeか,という議論ですが,
まだまだRS232Cで動いているデバイスが多いと思いますが,
それ以外でもLinuxでは対応するデバイスファイル名が,
システムによって変更になるので,コンフィグを変更する必要が出てきます.
バイナリで配布しようとすると,結構大事な機能です.

ファイルを開くタイミングですが,
これをonInitializeで行う場合は,rtc.conf,もしくはそれで指定される
***.confのファイル内で,COMポート名もしくは
ファイル名を指定するしかありません.
(さらにonInitializeで**.confにある内容を
読み込むためにはupdateParameterなる関数を
onInitialize内で最初に実行する必要があったはずですが,
開発者が自分で追加する必要があったし,
マニュアルが無いと思いますが・・・)

onActivatedで行う場合は,デフォルトの値をrtc.confなどに指定しておき,
System Editorやその他のツールで変更してからActivateを掛けられる.
この機能はリモートからrtcdを使ってサービスを起動した場合にも便利です.

ということで,onActivatedでのファイルオープンが
優れていると思っています.
また,デバイス自体を強制停止・再起動したい場合も,
deactiveを掛けてファイルクローズさせて,
USBなどで抜き差しして再度activateさせるという荒業も許容してくれます.

まあ,どっちでもいい,という気持ちがかなりあるんですが,
出来れば開発の指針を,いろんなところで示してもらえると
とっても良いと思っています.

(2010/12/30 1:28), kurihara shinji wrote:
> OpenRTM-aistメーリングリストの皆様
>
> お世話になっております。
> 産総研 栗原です。
>
> 先日開催されましたSI2010での「RTミドルウエアコンテスト2010」にてご質問またはコメ
> ント頂きました内容について、遅くなりましたが、回答させて頂きます。
>
> なお、本メールは、SI2010に参加されなかった方にも情報を共有していただければと思い
> 、この ML に流させて頂いております。
>
> Q1. onInitialize/onFinalizeでデバイスのオープン処理やメモリ領域の確保/破棄を
>   行うのではなく、onActivated/onDeactivatedで行った方がよいのでは?
>
> A1. ・そのRTCにて、デバイスを独占したい場合などは、onInitializeの段階にてデバイ
>    スデバイスのオープンを行った方がよい。
>   ・RAII(Resource Acquisition Is Initialization)イディオムをRTCにあてはめると
> onInitialize/onFinalizeに相当するのでは。
>   ・RTCで扱うデバイスや、目的によりonInitializeにするか、onActivatedにするか
>    判断する必要がある。
>
> Q2. OpenRTM-aist-1.0.0ではバッファリングポリシーが導入されており、データが読み込
>   み可能かを確認するためにはread() の戻り値を確認すればよいので、isNew()は必要
>   ないのでは?
> A2. ・バッファが空の状態でもブロックしないようにバッファリングポリシーが正しく設
>    定されていればread()での確認でもよい。
>   ・バッファが空の状態で、データが読み込み可能かを確認するためには、read()より
>    isNew()の方が処理が単純で早い。
> ・read()では、push接続においてInPortに届いたデータが最新かどうかの判断はでき
> ない。
>
> Q3. 開発者は、push型で接続するのを想定して作成されたが、ユーザーがpull型で接続さ
>   れるといった懸念事項がある。これを制限するにはどうすればよいのか?
> A3. ・component.confなどのコンフィグレーションファイルにてdataflow_typeを指定
>    して、これを接続時に反映できるように検討させて頂きます。
>
> Q4. デベロッパーズガイドを早く完成させてほしい。
> A4. 現在、執筆中ですので、もうしばらくお待ち下さい。
>
>
> 何かコメント等ございましたら、ご遠慮なく頂ければと存じます。
> 以上、宜しくお願い致します。
>

root
オフライン
Last seen: 3時間 35分 前
登録日: 2009-06-23 14:31
[openrtm-users 01522] SI2010でのRTミドルウエアに関する質疑応答

株式会社リバスト 菅様

お世話になっております。
産総研 栗原です。

貴重なご意見を頂き、誠にありがとうございます。

今回の問題やその他RTCの作成に関しましては、確かに菅さんがおっしゃる通り、
ある程度の指針が必要だと我々も考えております。
実際、まだ完成はしておりませんが、OpenRTM-aistページの ドキュメント > デベロッ
パーズガイドページを安藤さんが執筆中ですので、こちらが完成すれば、
ある程度のRTC作成に関するポリシーなどは明示できるのではと考えております。

私自身もRTCを作成する際に、onInitializeで初期化(メモリ確保やデバイスオープン)
を行うべきか、onActivatedで行うべきか悩む事がございます。
(私も、onActivatedでの初期化が多いのですが。。。)
なんらかのハードウェアを扱うRTCで、かつ、そのRTCがハードウェアにアクセスでき
なければRTCとして存在するべきではないといった仕様の場合は、onInitializeで
デバイスオープンを行い、失敗したらRTCの生成も失敗とするといった作成の仕方も
ございますし、どちらで初期化を行うかは作成するRTCによるのではと考えております。
ただ、この辺りの情報につきましても明確にはしてませんので、合わせてデベロッパーズ
ガイドに反映するように致します。

他にもお気づきの点がございましたら、コメント頂ければ幸いです。

来年もどうぞ、宜しくお願い致します。

On Thu, 30 Dec 2010 01:52:41 +0900
ysuga wrote:

> リバストの菅です.
> お世話になっております.
>
> >栗原様:
> ご苦労様です.
>
>
> Q1に対してです.
> 結構,どうでもいいと思っている部分もありますが,
> その半面,大事な問題を含んでいると思っています.
> ある程度,「こうして作ってください」というポリシーがあると,
> 分かりやすい,と思う人が多い,と考えています.
>
> 現状では,このメーリングリストに登録している人も,
> アーリーアダプターの人ばかりでしょうが,
> 他の人にも使ってもらうのであれば,
> プログラミングの基準を作るべきだし,
> そういうのが公式にあった方がやりやすいという人が,
> 特に日本人には多い気がします・・・
>
>
> さて,onActivatedかonInitializeか,という議論ですが,
> まだまだRS232Cで動いているデバイスが多いと思いますが,
> それ以外でもLinuxでは対応するデバイスファイル名が,
> システムによって変更になるので,コンフィグを変更する必要が出てきます.
> バイナリで配布しようとすると,結構大事な機能です.
>
> ファイルを開くタイミングですが,
> これをonInitializeで行う場合は,rtc.conf,もしくはそれで指定される
> ***.confのファイル内で,COMポート名もしくは
> ファイル名を指定するしかありません.
> (さらにonInitializeで**.confにある内容を
> 読み込むためにはupdateParameterなる関数を
> onInitialize内で最初に実行する必要があったはずですが,
> 開発者が自分で追加する必要があったし,
> マニュアルが無いと思いますが・・・)
>
>
> onActivatedで行う場合は,デフォルトの値をrtc.confなどに指定しておき,
> System Editorやその他のツールで変更してからActivateを掛けられる.
> この機能はリモートからrtcdを使ってサービスを起動した場合にも便利です.
>
> ということで,onActivatedでのファイルオープンが
> 優れていると思っています.
> また,デバイス自体を強制停止・再起動したい場合も,
> deactiveを掛けてファイルクローズさせて,
> USBなどで抜き差しして再度activateさせるという荒業も許容してくれます.
>
>
>
>
> まあ,どっちでもいい,という気持ちがかなりあるんですが,
> 出来れば開発の指針を,いろんなところで示してもらえると
> とっても良いと思っています.
>
>
>
> (2010/12/30 1:28), kurihara shinji wrote:
> > OpenRTM-aistメーリングリストの皆様
> >
> > お世話になっております。
> > 産総研 栗原です。
> >
> > 先日開催されましたSI2010での「RTミドルウエアコンテスト2010」にてご質問またはコメ
> > ント頂きました内容について、遅くなりましたが、回答させて頂きます。
> >
> > なお、本メールは、SI2010に参加されなかった方にも情報を共有していただければと思い
> > 、この ML に流させて頂いております。
> >
> > Q1. onInitialize/onFinalizeでデバイスのオープン処理やメモリ領域の確保/破棄を
> >   行うのではなく、onActivated/onDeactivatedで行った方がよいのでは?
> >
> > A1. ・そのRTCにて、デバイスを独占したい場合などは、onInitializeの段階にてデバイ
> >    スデバイスのオープンを行った方がよい。
> >   ・RAII(Resource Acquisition Is Initialization)イディオムをRTCにあてはめると
> > onInitialize/onFinalizeに相当するのでは。
> >   ・RTCで扱うデバイスや、目的によりonInitializeにするか、onActivatedにするか
> >    判断する必要がある。
> >
> > Q2. OpenRTM-aist-1.0.0ではバッファリングポリシーが導入されており、データが読み込
> >   み可能かを確認するためにはread() の戻り値を確認すればよいので、isNew()は必要
> >   ないのでは?
> > A2. ・バッファが空の状態でもブロックしないようにバッファリングポリシーが正しく設
> >    定されていればread()での確認でもよい。
> >   ・バッファが空の状態で、データが読み込み可能かを確認するためには、read()より
> >    isNew()の方が処理が単純で早い。
> > ・read()では、push接続においてInPortに届いたデータが最新かどうかの判断はでき
> > ない。
> >
> > Q3. 開発者は、push型で接続するのを想定して作成されたが、ユーザーがpull型で接続さ
> >   れるといった懸念事項がある。これを制限するにはどうすればよいのか?
> > A3. ・component.confなどのコンフィグレーションファイルにてdataflow_typeを指定
> >    して、これを接続時に反映できるように検討させて頂きます。
> >
> > Q4. デベロッパーズガイドを早く完成させてほしい。
> > A4. 現在、執筆中ですので、もうしばらくお待ち下さい。
> >
> >
> > 何かコメント等ございましたら、ご遠慮なく頂ければと存じます。
> > 以上、宜しくお願い致します。
> >
>

root
オフライン
Last seen: 3時間 35分 前
登録日: 2009-06-23 14:31
[openrtm-users 01523] SI2010でのRTミドルウエアに関する質疑応答

栗原様、菅様

産総研のジェフです。

これは私自身のポリシ(産総研やOpenRTMのではなく)ですが、ランタイムでコ
ンフィグレーションで変更するべきことはonActivatedに初期化して、コンフィ
グレーションで設定できないと変更するべきではないことはonInitializeで初期
化します。

ハードウェアのデバイスの場合、コンフィグレーションファイルで買いて
onInitializeに初期化するといいと思います。そして、必要ならonResetにまた
初期化する。

onInitializeはクラスのコンストラクターのように思いたいんですが、クラスの
場合は全部のパラメータをもらえるようにさせます。onInitializeはそれがしに
くいです。*.confに書いても、ダイナミクな特徴がなくなるのでちょっとやりた
くないことですね。

では、よいお年を!ことしもよろしくお願いいたします。

On 31/12/10 01:30, kurihara shinji wrote:
> 株式会社リバスト 菅様
>
> お世話になっております。
> 産総研 栗原です。
>
> 貴重なご意見を頂き、誠にありがとうございます。
>
> 今回の問題やその他RTCの作成に関しましては、確かに菅さんがおっしゃる通り、
> ある程度の指針が必要だと我々も考えております。
> 実際、まだ完成はしておりませんが、OpenRTM-aistページの ドキュメント > デベロッ
> パーズガイドページを安藤さんが執筆中ですので、こちらが完成すれば、
> ある程度のRTC作成に関するポリシーなどは明示できるのではと考えております。
>
> 私自身もRTCを作成する際に、onInitializeで初期化(メモリ確保やデバイスオープン)
> を行うべきか、onActivatedで行うべきか悩む事がございます。
> (私も、onActivatedでの初期化が多いのですが。。。)
> なんらかのハードウェアを扱うRTCで、かつ、そのRTCがハードウェアにアクセスでき
> なければRTCとして存在するべきではないといった仕様の場合は、onInitializeで
> デバイスオープンを行い、失敗したらRTCの生成も失敗とするといった作成の仕方も
> ございますし、どちらで初期化を行うかは作成するRTCによるのではと考えております。
> ただ、この辺りの情報につきましても明確にはしてませんので、合わせてデベロッパーズ
> ガイドに反映するように致します。
>
> 他にもお気づきの点がございましたら、コメント頂ければ幸いです。
>
>
> 来年もどうぞ、宜しくお願い致します。
>
>
>
> On Thu, 30 Dec 2010 01:52:41 +0900
> ysuga wrote:
>
>> リバストの菅です.
>> お世話になっております.
>>
>> >栗原様:
>> ご苦労様です.
>>
>>
>> Q1に対してです.
>> 結構,どうでもいいと思っている部分もありますが,
>> その半面,大事な問題を含んでいると思っています.
>> ある程度,「こうして作ってください」というポリシーがあると,
>> 分かりやすい,と思う人が多い,と考えています.
>>
>> 現状では,このメーリングリストに登録している人も,
>> アーリーアダプターの人ばかりでしょうが,
>> 他の人にも使ってもらうのであれば,
>> プログラミングの基準を作るべきだし,
>> そういうのが公式にあった方がやりやすいという人が,
>> 特に日本人には多い気がします・・・
>>
>>
>> さて,onActivatedかonInitializeか,という議論ですが,
>> まだまだRS232Cで動いているデバイスが多いと思いますが,
>> それ以外でもLinuxでは対応するデバイスファイル名が,
>> システムによって変更になるので,コンフィグを変更する必要が出てきます.
>> バイナリで配布しようとすると,結構大事な機能です.
>>
>> ファイルを開くタイミングですが,
>> これをonInitializeで行う場合は,rtc.conf,もしくはそれで指定される
>> ***.confのファイル内で,COMポート名もしくは
>> ファイル名を指定するしかありません.
>> (さらにonInitializeで**.confにある内容を
>> 読み込むためにはupdateParameterなる関数を
>> onInitialize内で最初に実行する必要があったはずですが,
>> 開発者が自分で追加する必要があったし,
>> マニュアルが無いと思いますが・・・)
>>
>>
>> onActivatedで行う場合は,デフォルトの値をrtc.confなどに指定しておき,
>> System Editorやその他のツールで変更してからActivateを掛けられる.
>> この機能はリモートからrtcdを使ってサービスを起動した場合にも便利です.
>>
>> ということで,onActivatedでのファイルオープンが
>> 優れていると思っています.
>> また,デバイス自体を強制停止・再起動したい場合も,
>> deactiveを掛けてファイルクローズさせて,
>> USBなどで抜き差しして再度activateさせるという荒業も許容してくれます.
>>
>>
>>
>>
>> まあ,どっちでもいい,という気持ちがかなりあるんですが,
>> 出来れば開発の指針を,いろんなところで示してもらえると
>> とっても良いと思っています.
>>
>>
>>
>> (2010/12/30 1:28), kurihara shinji wrote:
>>> OpenRTM-aistメーリングリストの皆様
>>>
>>> お世話になっております。
>>> 産総研 栗原です。
>>>
>>> 先日開催されましたSI2010での「RTミドルウエアコンテスト2010」にてご質問またはコメ
>>> ント頂きました内容について、遅くなりましたが、回答させて頂きます。
>>>
>>> なお、本メールは、SI2010に参加されなかった方にも情報を共有していただければと思い
>>> 、この ML に流させて頂いております。
>>>
>>> Q1. onInitialize/onFinalizeでデバイスのオープン処理やメモリ領域の確保/破棄を
>>>   行うのではなく、onActivated/onDeactivatedで行った方がよいのでは?
>>>
>>> A1. ・そのRTCにて、デバイスを独占したい場合などは、onInitializeの段階にてデバイ
>>>    スデバイスのオープンを行った方がよい。
>>>   ・RAII(Resource Acquisition Is Initialization)イディオムをRTCにあてはめると
>>> onInitialize/onFinalizeに相当するのでは。
>>>   ・RTCで扱うデバイスや、目的によりonInitializeにするか、onActivatedにするか
>>>    判断する必要がある。
>>>
>>> Q2. OpenRTM-aist-1.0.0ではバッファリングポリシーが導入されており、データが読み込
>>>   み可能かを確認するためにはread() の戻り値を確認すればよいので、isNew()は必要
>>>   ないのでは?
>>> A2. ・バッファが空の状態でもブロックしないようにバッファリングポリシーが正しく設
>>>    定されていればread()での確認でもよい。
>>>   ・バッファが空の状態で、データが読み込み可能かを確認するためには、read()より
>>>    isNew()の方が処理が単純で早い。
>>> ・read()では、push接続においてInPortに届いたデータが最新かどうかの判断はでき
>>> ない。
>>>
>>> Q3. 開発者は、push型で接続するのを想定して作成されたが、ユーザーがpull型で接続さ
>>>   れるといった懸念事項がある。これを制限するにはどうすればよいのか?
>>> A3. ・component.confなどのコンフィグレーションファイルにてdataflow_typeを指定
>>>    して、これを接続時に反映できるように検討させて頂きます。
>>>
>>> Q4. デベロッパーズガイドを早く完成させてほしい。
>>> A4. 現在、執筆中ですので、もうしばらくお待ち下さい。
>>>
>>>
>>> 何かコメント等ございましたら、ご遠慮なく頂ければと存じます。
>>> 以上、宜しくお願い致します。
>>>
>>
>
>

root
オフライン
Last seen: 3時間 35分 前
登録日: 2009-06-23 14:31
[openrtm-users 01529] SI2010でのRTミドルウエアに関する質疑応答

株式会社セック 小田桐です。
お世話になっております。

初期化のタイミングについては、私も個人的な意見ですが、
onActivatedでおこなうのが良いと考えています。

おそらく使っている方はほとんどいないと思いますが、
初期化はonStartupでおこなうという選択肢もあります。
onInitialize/onStartup/onActivatedのそれぞれの意味や
理想的な使い分けを考え出すといろいろご意見があるだろうと思いますが、
私は最近、実装上のメリットを考えてonActivatedのみで初期化をしています。

菅様がおっしゃっているコンフィギュレーションのメリットもありますが、
もうひとつ、マルチスレッドの問題もあります。

今のOpenRTM-aistの実装では、RTCのコンストラクタやonInitializeが
実行されるスレッドと、onActivated/onDeactivated/onExecuteが実行される
スレッドが異なります。
WindowsのCOM(Component Object Model)を使ったライブラリには、
単一のスレッドからしか直接の操作ができないものがあり、そういった
ライブラリをRTCで使う場合に問題が発生する場合があります。

私は、カメラキャプチャのためのvideoInputというライブラリで
この問題に遭遇しました。
onInitializeでカメラデバイスを開くと、onExecute内でカメラが使えない、
という現象がおきました。
videoInputのソースを見てみると、シングルスレッドのモードでCOMを
使っていたため、onInitializeで開いたデバイスに、別スレッドで実行された
onExecuteからはアクセスできなかったようです。
onActivatedでカメラデバイスを開くことで解決できました。

これは、OpenRTM-aistの内部構造を知っていれば解決できますが、
知らないと解決が難しそうな問題です。
onActivated/onDeactivated/onExecuteのみを使っていれば、
コアロジック自体は基本的にシングルスレッドで実行されるため、
上記のような問題は発生しなくなると思います。

main関数内に直接処理を書いた普通のプログラムではうまく動くけど、
RTCに組み込むとなぜかうまく動かない、という事態を防ぐような仕組みや、
RTC作成のポリシーがあるとよいと思っています。

以上です。

On Sat, 01 Jan 2011 11:01:38 +0900
Geoffrey Biggs wrote:

> 栗原様、菅様
>
> 産総研のジェフです。
>
> これは私自身のポリシ(産総研やOpenRTMのではなく)ですが、ランタイムでコ
> ンフィグレーションで変更するべきことはonActivatedに初期化して、コンフィ
> グレーションで設定できないと変更するべきではないことはonInitializeで初期
> 化します。
>
> ハードウェアのデバイスの場合、コンフィグレーションファイルで買いて
> onInitializeに初期化するといいと思います。そして、必要ならonResetにまた
> 初期化する。
>
> onInitializeはクラスのコンストラクターのように思いたいんですが、クラスの
> 場合は全部のパラメータをもらえるようにさせます。onInitializeはそれがしに
> くいです。*.confに書いても、ダイナミクな特徴がなくなるのでちょっとやりた
> くないことですね。
>
> では、よいお年を!ことしもよろしくお願いいたします。
>
>
> On 31/12/10 01:30, kurihara shinji wrote:
> > 株式会社リバスト 菅様
> >
> > お世話になっております。
> > 産総研 栗原です。
> >
> > 貴重なご意見を頂き、誠にありがとうございます。
> >
> > 今回の問題やその他RTCの作成に関しましては、確かに菅さんがおっしゃる通り、
> > ある程度の指針が必要だと我々も考えております。
> > 実際、まだ完成はしておりませんが、OpenRTM-aistページの ドキュメント > デベロッ
> > パーズガイドページを安藤さんが執筆中ですので、こちらが完成すれば、
> > ある程度のRTC作成に関するポリシーなどは明示できるのではと考えております。
> >
> > 私自身もRTCを作成する際に、onInitializeで初期化(メモリ確保やデバイスオープン)
> > を行うべきか、onActivatedで行うべきか悩む事がございます。
> > (私も、onActivatedでの初期化が多いのですが。。。)
> > なんらかのハードウェアを扱うRTCで、かつ、そのRTCがハードウェアにアクセスでき
> > なければRTCとして存在するべきではないといった仕様の場合は、onInitializeで
> > デバイスオープンを行い、失敗したらRTCの生成も失敗とするといった作成の仕方も
> > ございますし、どちらで初期化を行うかは作成するRTCによるのではと考えております。
> > ただ、この辺りの情報につきましても明確にはしてませんので、合わせてデベロッパーズ
> > ガイドに反映するように致します。
> >
> > 他にもお気づきの点がございましたら、コメント頂ければ幸いです。
> >
> >
> > 来年もどうぞ、宜しくお願い致します。
> >
> >
> >
> > On Thu, 30 Dec 2010 01:52:41 +0900
> > ysuga wrote:
> >
> >> リバストの菅です.
> >> お世話になっております.
> >>
> >> >栗原様:
> >> ご苦労様です.
> >>
> >>
> >> Q1に対してです.
> >> 結構,どうでもいいと思っている部分もありますが,
> >> その半面,大事な問題を含んでいると思っています.
> >> ある程度,「こうして作ってください」というポリシーがあると,
> >> 分かりやすい,と思う人が多い,と考えています.
> >>
> >> 現状では,このメーリングリストに登録している人も,
> >> アーリーアダプターの人ばかりでしょうが,
> >> 他の人にも使ってもらうのであれば,
> >> プログラミングの基準を作るべきだし,
> >> そういうのが公式にあった方がやりやすいという人が,
> >> 特に日本人には多い気がします・・・
> >>
> >>
> >> さて,onActivatedかonInitializeか,という議論ですが,
> >> まだまだRS232Cで動いているデバイスが多いと思いますが,
> >> それ以外でもLinuxでは対応するデバイスファイル名が,
> >> システムによって変更になるので,コンフィグを変更する必要が出てきます.
> >> バイナリで配布しようとすると,結構大事な機能です.
> >>
> >> ファイルを開くタイミングですが,
> >> これをonInitializeで行う場合は,rtc.conf,もしくはそれで指定される
> >> ***.confのファイル内で,COMポート名もしくは
> >> ファイル名を指定するしかありません.
> >> (さらにonInitializeで**.confにある内容を
> >> 読み込むためにはupdateParameterなる関数を
> >> onInitialize内で最初に実行する必要があったはずですが,
> >> 開発者が自分で追加する必要があったし,
> >> マニュアルが無いと思いますが・・・)
> >>
> >>
> >> onActivatedで行う場合は,デフォルトの値をrtc.confなどに指定しておき,
> >> System Editorやその他のツールで変更してからActivateを掛けられる.
> >> この機能はリモートからrtcdを使ってサービスを起動した場合にも便利です.
> >>
> >> ということで,onActivatedでのファイルオープンが
> >> 優れていると思っています.
> >> また,デバイス自体を強制停止・再起動したい場合も,
> >> deactiveを掛けてファイルクローズさせて,
> >> USBなどで抜き差しして再度activateさせるという荒業も許容してくれます.
> >>
> >>
> >>
> >>
> >> まあ,どっちでもいい,という気持ちがかなりあるんですが,
> >> 出来れば開発の指針を,いろんなところで示してもらえると
> >> とっても良いと思っています.
> >>
> >>
> >>
> >> (2010/12/30 1:28), kurihara shinji wrote:
> >>> OpenRTM-aistメーリングリストの皆様
> >>>
> >>> お世話になっております。
> >>> 産総研 栗原です。
> >>>
> >>> 先日開催されましたSI2010での「RTミドルウエアコンテスト2010」にてご質問またはコメ
> >>> ント頂きました内容について、遅くなりましたが、回答させて頂きます。
> >>>
> >>> なお、本メールは、SI2010に参加されなかった方にも情報を共有していただければと思い
> >>> 、この ML に流させて頂いております。
> >>>
> >>> Q1. onInitialize/onFinalizeでデバイスのオープン処理やメモリ領域の確保/破棄を
> >>>   行うのではなく、onActivated/onDeactivatedで行った方がよいのでは?
> >>>
> >>> A1. ・そのRTCにて、デバイスを独占したい場合などは、onInitializeの段階にてデバイ
> >>>    スデバイスのオープンを行った方がよい。
> >>>   ・RAII(Resource Acquisition Is Initialization)イディオムをRTCにあてはめると
> >>> onInitialize/onFinalizeに相当するのでは。
> >>>   ・RTCで扱うデバイスや、目的によりonInitializeにするか、onActivatedにするか
> >>>    判断する必要がある。
> >>>
> >>> Q2. OpenRTM-aist-1.0.0ではバッファリングポリシーが導入されており、データが読み込
> >>>   み可能かを確認するためにはread() の戻り値を確認すればよいので、isNew()は必要
> >>>   ないのでは?
> >>> A2. ・バッファが空の状態でもブロックしないようにバッファリングポリシーが正しく設
> >>>    定されていればread()での確認でもよい。
> >>>   ・バッファが空の状態で、データが読み込み可能かを確認するためには、read()より
> >>>    isNew()の方が処理が単純で早い。
> >>> ・read()では、push接続においてInPortに届いたデータが最新かどうかの判断はでき
> >>> ない。
> >>>
> >>> Q3. 開発者は、push型で接続するのを想定して作成されたが、ユーザーがpull型で接続さ
> >>>   れるといった懸念事項がある。これを制限するにはどうすればよいのか?
> >>> A3. ・component.confなどのコンフィグレーションファイルにてdataflow_typeを指定
> >>>    して、これを接続時に反映できるように検討させて頂きます。
> >>>
> >>> Q4. デベロッパーズガイドを早く完成させてほしい。
> >>> A4. 現在、執筆中ですので、もうしばらくお待ち下さい。
> >>>
> >>>
> >>> 何かコメント等ございましたら、ご遠慮なく頂ければと存じます。
> >>> 以上、宜しくお願い致します。
> >>>
> >>
> >
> >
>

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

ダウンロード

最新バージョン : 2.0.1-RELESE

統計

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

Choreonoid

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

OpenHRP3

動力学シミュレータ

OpenRTP

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

産総研RTC集

産総研が提供するRTC集

TORK

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

DAQ-Middleware

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