[openrtm-users 02398] Re: ECから時刻をとれるようにする

池添明宏 ikezoe ＠ sec.co.jp
2012年 1月 16日 (月) 22:15:53 JST 

安藤様

池添です。

>> 私も若干コンセプトは違うのですが、後者の方針のようなものを試験的に
>> 実装したことがあります。（C++ではないのですが）
>
> やはりそういう需要は色々とあるんですね。
> ちなみに、どんなシステムで使用したのでしょうか？

需要があったわけではないのですが、複数データポートの同期待ちや、
複数スレッド間の同期を簡単に書ければ便利ではないかと思い、
試しに実装してみたものです。
論理時間で動かせるようにしたのは、その中の一部の機能です。


>> そのときは、時間とスレッドの動きを管理するスケジューラクラスを、
>> ECとRTCから参照するようなモデルとしました。
>> # このため、ECとRTCが同一メモリ上にないと動作しません・・・
>>
>> スケジューラは、実際の時間のものと論理時間のものを切り替えられる
>> ようにしました。
>> 論理時間のスケジューラは、例えば、スケジューラの時間を10秒進めると、
>> 1秒周期のECの周期処理が10回動作するような仕組みになっています。
>> 周期の異なる複数のECを、1つのスケジューラで制御することも可能です。
>
> これは、スケジューラ：スレッド=1:1という関係でしょうか？

基本的には1:1になります。
コールバック関数をキューに登録しておいて、任意のタイミング（周期的なタイミングや
イベント発生時）にコールバック関数をキューから取り出し、順次動作させるような仕組み
になっております。


>> ちなみに、データポートのコールバックやセンサ用の受信スレッドと、ECの
>> スレッドを同期させることも考えているので、スケジューラは時間だけでなく
>> スレッドも併せて管理するような構成としています。
>
> 確かに、いろいろなものをECのトリガにしたいケースは色々有りそうですね。
> 可能でしたら、もう少し具体的な使い方を教えていただけますか？

例えば、データポートのコールバックと、コンポーネントのアクティビティを
同じスレッドで動かすことにより、同じリソースにアクセスする場合に
明示的な排他制御を不要にできたりします。


もとの話題から少しずれてしまいましたね…

以上です。



(2012/01/13 11:07), Ando Noriaki wrote:
> 池添さん
> 
> 安藤です
> 
> コメントありがとうございます。
> 
> 2012年1月11日12:49 池添明宏<ikezoe ＠ sec.co.jp>:
>> 池添です。
>>
>> 私も若干コンセプトは違うのですが、後者の方針のようなものを試験的に
>> 実装したことがあります。（C++ではないのですが）
> 
> やはりそういう需要は色々とあるんですね。
> ちなみに、どんなシステムで使用したのでしょうか？
> 
>> そのときは、時間とスレッドの動きを管理するスケジューラクラスを、
>> ECとRTCから参照するようなモデルとしました。
>> # このため、ECとRTCが同一メモリ上にないと動作しません・・・
>>
>> スケジューラは、実際の時間のものと論理時間のものを切り替えられる
>> ようにしました。
>> 論理時間のスケジューラは、例えば、スケジューラの時間を10秒進めると、
>> 1秒周期のECの周期処理が10回動作するような仕組みになっています。
>> 周期の異なる複数のECを、1つのスケジューラで制御することも可能です。
> 
> これは、スケジューラ：スレッド=1:1という関係でしょうか？
> 
>> ちなみに、データポートのコールバックやセンサ用の受信スレッドと、ECの
>> スレッドを同期させることも考えているので、スケジューラは時間だけでなく
>> スレッドも併せて管理するような構成としています。
> 
> 確かに、いろいろなものをECのトリガにしたいケースは色々有りそうですね。
> 可能でしたら、もう少し具体的な使い方を教えていただけますか？
> 
>> 参考になるかどうか分かりませんが、以上です。
> 
> 大変参考になりました。ありがとうございました。
> 
> 
>>
>>
>>
>> (2012/01/10 13:26), Ando Noriaki wrote:
>>> 安藤です
>>>
>>> コメントありがとうございます。
>>>
>>> まず、coil::gettimeofday が論理時間を返すという機能を持つに当たって、
>>> これがRTMに依存するということはありません。
>>>
>>> 一般的な要求として、複数のノード間で時間を同期させたいということが
>>> あると思います。その際、coilレベルで、ノード間の時刻同期をさせることを
>>> 考えていました。（まだ実装はしていませんが。）
>>>
>>> この考え方を拡張して、coil::gettimeofdayを複数のクロックソースから
>>> 時刻を取得する機能を持たせたいと思っています。
>>>
>>> なので、まず1.については、この論理時間ECは、シミュレータ等の特殊な
>>> 用途で利用するためのもので、かつ論理時間は単一のアプリケーションが
>>> 全てを管理するので問題なし、という前提です。
>>> また、3.については、coilの論理時間クロックソースの機能にECが
>>> アクセスするだけですので、coilがRTMに依存することにはなりません。
>>>
>>> 2.については、前者も後者も実現できますね。一応、こういうインターフェースを
>>> 考えていますので。
>>>
>>> interface LogicalTimeTriggeredEC
>>>    : RTC::ExecutionContext
>>> {
>>>      void tick(in long sec, in long usec);
>>>      void get_time(out long sec, out long usec);
>>> };
>>>
>>>
>>> あと、ECにクロックを持たせる機能後者の方が美しいとのことですが、
>>> 実際インターフェースをどうするか考えると、あまり美しくはできないことが
>>> 分かると思います。
>>> RTC内のロジックがEC依存になってしまう恐れがあり、また最悪、
>>> RTC::ExecutionContext (LogicalTimeTriggeredECではなく) に
>>> get_time() オペレーションを追加しないと、希望のことが実現できないように思います。
>>> ＃ECは同一メモリ空間内にあるとは限りませんので。。。
>>>
>>> まぁ、菅さんがおっしゃるようにECから時刻を取得するというのは正しいと言えば正しいのですが、
>>> gettimeofdayで取得する時刻とECの時刻が違うというのも、変な気もします。
>>> とりあえず、いまは前者を実装していますが、後者についても考え中ということで。。。。
>>>
>>> 他にご意見のある方、よろしくお願いします。
>>>
>>>
>>>> 安藤先生，岡田先生，皆さま：
>>>> 菅です．お世話になっております．
>>>>
>>>> 前者はプロセス内部のグローバル時間を変更するEC，
>>>> 後者はEC内部にクロックを持ち，ECから時刻を取得する，
>>>> と判断します．
>>>>
>>>> これについては，後者がよいかと思いました．
>>>> 理由はぱっと考えると以下の二点．
>>>>
>>>> １．同一プロセス内でECを多数使う場合に，後者の方が混乱しないのでは？
>>>> ２．ECにアクセスして，他のプロセスからRTC内部の時刻にアクセスできそう
>>>> ３．coilがRTMに依存するモデルは美しくない
>>>>
>>>> ECで時刻を取得できるとなれば，利用したい場面が増えてくると思いますが，
>>>> 問題が切り分けやすそうな後者の方が魅力を感じます．
>>>> また，僕はRTC内では出来るだけcoilのオペレーションを使っていますが，
>>>> ECでcoil内部の値がすり替わるというのは，
>>>> coilがRTMに依存するということでしょうから，
>>>> coilを独立したモジュールとして開発していた意味もなくなってしまうのではないですか？
>>>>
>>>> 僕の感覚だと，「美しくない」です．
>>>>
>>>>
>>>> ではでは
>>>>
>>>> 2012年1月10日10:38 Ando Noriaki<n-ando ＠ aist.go.jp>:
>>>>> 岡田先生、皆様
>>>>>
>>>>> 安藤です
>>>>>
>>>>> 我々も、とある用途でそういった仕様のECを検討しています。
>>>>>
>>>>> 具体的に言いますと、現在のECのトリガオペレーション tick() の代わりに
>>>>> tick (in long sec, in long usec) を使ってアプリケーション側から
>>>>> 時刻を与えられるようにし、ECは与えられた時刻を論理クロック
>>>>> (グローバルに1個、論理時間を保持するだけのもの) に書き込み、
>>>>> coil::gettimeofday() が返す値に反映させる、というものです。
>>>>> ＃添付のホワイトボードの図を参照ください。
>>>>>
>>>>> もう一つ考えているのは、この論理クロックをEC内部に持たせ、
>>>>> RTObject_implにECの時刻を取得するメンバ関数を追加するというものです。
>>>>>
>>>>> 最初の方法は、クロックを論理クロックに切り替えたあとは、
>>>>> すべてcoil:gettimeofday で取得した時刻が論理時間に切り替わるので、
>>>>> 例えば、ログに記録される時刻もすべて論理時間と同じになるので、
>>>>> 挙動とログを照らし合わせるときなどは便利ですが、そのたgettimeofday
>>>>> に依存してロジックを組んでいる場合、そこでおかしな現象が起こる可能性もあります。
>>>>>
>>>>> 後者は、ECに論理時間を取得しに行くロジックだけ、論理時間を元に
>>>>> 動作するのでわかりやすいといえばわかりやすいですが、他の時刻は
>>>>> 実際のクロックのままです。
>>>>>
>>>>> 今のところ、前者の実装を行なっているところですが、みなさんでなにか
>>>>> アイディアがおありの方がいらっしゃいましたら、コメントいただければ幸いです。
>>>>>
>>>>> よろしくお願いします。
>>>>>
>>>>>
>>>>> 2012年1月6日18:10 Kei Okada<k-okada ＠ jsk.t.u-tokyo.ac.jp>:
>>>>>> 岡田です．度々お騒がせしております．
>>>>>>
>>>>>> ECから時刻をとれるようにする，という機能があると以下の状況で
>>>>>> 便利かと思いましたので，よろしくご検討いただければ幸いです．
>>>>>>
>>>>>> ー
>>>>>> シミュレータと実機で同じコンポーネントを使うような状況で，
>>>>>> コンポーネント内で，例えば実行周期を確認する為などの場合で，
>>>>>> シミュレータではシミュレーションの時刻を知りたく，実機では実時刻を
>>>>>> 知りたい場合，ECから現在の時刻をとれるような機能があれば，
>>>>>> コンポーネントでonExecuteが呼ばれる度にこれを参照する，という
>>>>>> プログラムがかけそうです
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> ///////////////////////////////////////////////////////////////////
>>>> // Yuki Suga, Ph.D.
>>>> // URL: http://www.ysuga.net/?lang=en
>>>> // E-mail: ysuga ＠ ysuga.net
>>>> ///////////////////////////////////////////////////////////////////
>>>> _______________________________________________
>>>> openrtm-users mailing list
>>>> openrtm-users ＠ openrtm.org
>>>> http://www.openrtm.org/mailman/listinfo/openrtm-users
>>>
>>>
>>>
>>
>>
>> --
>>
>> ----------------------------------------------
>> 株式会社セック 開発本部 第四開発部
>> 池添 明宏 ikezoe ＠ sec.co.jp
>> 〒158-0097 東京都世田谷区用賀4-10-1 SBSビル
>> TEL： 03-5491-4404 FAX： 03-5491-4771
>> ----------------------------------------------
>>
>> ======================================================================
>> この電子メールの内容および添付されている情報は、機密情報であると同時に、
>> 宛先として意図した特定の受信者のみに送信いたしております。当方の誤送信
>> 等により、心当たりのない方が受信された場合は、大変お手数ですが、受信さ
>> れましたメール内容は削除していただきますようお願いいたします。
>> ======================================================================
>> _______________________________________________
>> 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
> 
> 


-- 

----------------------------------------------
株式会社セック 開発本部 第四開発部
池添 明宏 ikezoe ＠ sec.co.jp
〒158-0097 東京都世田谷区用賀4-10-1 SBSビル
TEL： 03-5491-4404 FAX： 03-5491-4771
----------------------------------------------

======================================================================
この電子メールの内容および添付されている情報は、機密情報であると同時に、
宛先として意図した特定の受信者のみに送信いたしております。当方の誤送信
等により、心当たりのない方が受信された場合は、大変お手数ですが、受信さ
れましたメール内容は削除していただきますようお願いいたします。
======================================================================

openrtm-users メーリングリストの案内