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

Kei Okada k-okada ＠ jsk.t.u-tokyo.ac.jp
2013年 1月 8日 (火) 11:33:31 JST 

岡田です．

古い話になりましたが，やはりこの機能が必要ですね，という声が私の周囲で聞こえてきましたので，
掘り起こしてみました．既に対応済みでしたら無視してください．

私の感覚的には前者だと，coil::gettimeofday() を呼べばシミュレーションなら論理時間が，
実機なら実時間が帰ってくるので，ユーザ側からすると，やや使いやすいのかな，と思いました．
％　とはいえ，色々な見方がありますね，

2012/1/16 池添明宏 <ikezoe ＠ sec.co.jp>:
> 安藤様
>
> 池添です。
>
>>> 私も若干コンセプトは違うのですが、後者の方針のようなものを試験的に
>>> 実装したことがあります。（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 mailing list
> openrtm-users ＠ openrtm.org
> http://www.openrtm.org/mailman/listinfo/openrtm-users

More information about the openrtm-users mailing list