[openrtm-users 00962] Re: OpenRTM-aist-1.0.0-RC1 (C++) DataPort型データのTimeStamp不具合

2009年 9月 28日 (月) 12:58:48 JST

安藤様、皆様：

産総研の原です。
DataPortのTimeStamp に関してなのですが、そもそも 
DataPortで送受信されるTimeが
RTCを使ったシステムでどのように使われるかという統一見解がない 
のが問題なのでは
ないでしょうか？
DataPortを流れるデータが、デスクトップのアプリのイベントのよ 
うなものであると考えると、
イベント発生時の時間を保持すべきではないでしょうか。
これは、センサーでのイベント発生時刻を保持するということであ 
り、この発生時刻が重要な
場面はロボットのシステムでは、非常に多くあると思います。（セ 
ンサーフュージョンを行う
場合に、センシングデータの同時性が重要になりますので）
安藤さんのおっしゃるような、Timeの使い方をする場合に 
は、どちらかというと通信部分の
ヘッダーに書くべきのような気がしますが、いかがでしょうか？

On 2009/09/28, at 12:35, Ando Noriaki wrote:

> 中島様、金広様、OpenRTM MLの皆様
>
> 産総研 安藤です
>
> これに関しては、MLに参加していただいている皆さんにも
> お聞きしたいトピックです。ぜひご意見ください。
>
>> 産総研の中島です。
>>
>> OpenRTM-aist-1.0.0-RC1 (C++) をUbuntu8.04環境で使用 
>> していますが、
>> データポート送信における、タイムスタンプの扱いに不具合があ 
>> るよう
>> ですので報告します。
>
>> DataPort型データを送信する際に、例えば「Timed～～」 
>> 型で定義していると、
>> 「tm」がも送信されますが、0.4.2では確か「空っ 
>> ぽ」でユーザーが自らセット
>> する仕様だったと思いますが、1.0.0では、自動でCPU 
>> 時刻が付与されているようです。
>>
>> これは仕様でしょうか？またどのタイミングの時刻でしょうか？
>
> ドキュメントに書いてないので、不具合といわれるとそうなのか 
> もしれませんが、
> 私としては仕様のつもりでした。申し訳ございません。
> 基本的に、データポートのデータのタイムスタンプは、
> 「OutPortに対してwrite()された時刻」というルー 
> ルになっております。
>
> OutPort.h の write() の中で以下のように時刻を代入して 
> おります。
>
>      // set timestamp
>      coil::TimeValue tm(coil::gettimeofday());
>      value.tm.sec  = tm.sec();
>      value.tm.nsec = tm.usec() * 1000;
>
>
>> 上記を踏まえて、利用していると以下２点問題があります。
>>
>> ===
>>
>> 【１】同一データを複数のRTC間を経由する際のタイムス 
>> タンプの上書き
>>
>> テスト用に、RTCを３つ用意し、「testA」- 
>> >「testB」->「testC」
>> という順に、「testA」で作成したデータを送信し、 
>> 「testB」で受信し、
>> そのまま送信用にコピーし再送信、「testC」で受信とい 
>> う一連の処理を
>> する場合をテストしました。
>> 「testA」内部で"tm.sec","tm.nsec"に値を入れて 
>> 送信しても、「testB」で受信
>> し、中身を見ると、"tm.sec","tm.nsec"はCPU時刻 
>> にて上書きされています。
>> （どのタイミングでの時刻か不明ですが・・）
>> さらに、上書きされたデータを「testB」が 
>> 「testC」に送信し、「testC」が受
>> 信し、中身を見ると、"tm.sec","tm.nsec"は 
>> 「testB」で見た時刻とは異なり、
>> 新たに時刻が上書きされていることが判明しています。
>> つまり、唯一のでデータが送信の度に変更されてしまっている状態。
>
> これは、
> 「testA」->「testB」->「testC」
> という構成において、testBのInPortとOutPort 
> は、データが唯一のものである
> という前提を知る由もないので致し方ないのではないでしょうか？
> そもそも、testBはInPortから来たデータに何か処理 
> を施して、OutPort
> から出すわけですので、その時点で元々のデータとは異なるデー 
> タになるので
> おっしゃるような「唯一のデータ」というのは前提として正しく 
> はないと思います。
>
> また、たとえば下の例のように、
>
> 「testA」-->「testB」->「testC」
> 「testA’」-/
>
> testBがtestA, testA' からのデータを受け取り
> testCにデータを出力する場合、testCに出力されるデータ 
> のタイムスタンプ
> はtestAのタイムスタンプでしょうか？testA'のタイ 
> ムスタンプでしょうか？
>
> 中島さんのあげられたフィルタ型のRTCは代表的なタイプで 
> すが、
> それ以外の入出力のRTCも存在するので、上記のような前提 
> を設ける
> のは難しいかと思います。
>
>> 【２】シミュレータ(OpenHRP3など)との兼ね合い
>>
>> 0.4.2までは、自動付与がないため、OpenHRP3からシミュ 
>> レーション上の時刻を
>> タイムスタンプとして取得可能でしたが、現在公開中の 
>> OpenHRP3.1.0_beta3では、
>> どうやら、この時刻もCPU時刻に上書きされているようです。
>> つまり、シミュレーション上の正確なデータを取得不可となって 
>> いる状態。
>>
>> ===
>>
>> この辺り、影響が大きいと思われますので、対応をお願いいたし 
>> ます。
>
> 具体的にはどのようにすればよろしいでしょうか？
>
> タイムスタンプに関する仕様は、使用状況によってさまざまなものが
> 要求されることは理解しています。しかしながら、OpenHRP 
> やその他
> タイムスタンプを前提としたアプリケーションでは、すべての 
> RTCが
> 統一されたルールに従う必要があります。でないと、RTCの 
> 再利用性が
> なくなってしまいますので。
>
> たとえば、上記の例 「testA」-- 
> >「testB」->「testC」 では、
> testA のみがタイムスタンプを打刻し、testBとtestC 
> は打刻しない
> という2つのルールが存在します。
> そこに、タイムスタンプを打刻するtestBとほぼ同等の 
> testB'というRTCを
> 代わりに挿入すると、上記の前提が崩れてしまいます。
>
> OpenHRPの構造として、ここのルールを統一することは不可能で 
> しょうか？＞金広さん
> たとえば、上記のタイムスタンプの時刻を与えている  
> coil::gettimeofday() を
> シミュレータが乗っ取り、任意の時刻を返すようにできるだけで 
> はだめですか？
>
> OutPortにwrite()された時点の「時刻を打刻する」というのは、
> ある意味簡潔で、比較的誰でも納得できる妥当なルールかなと
> 思うのですがいかがでしょうか？
>
> あとは、データポート接続時に、OutPort側もしくは 
> InPort側でタイムスタンプを
> 打刻する・しないを選択できるようにするという手もあります。
> 実装はできないことはないですが、いちいち指定するのはめんど 
> うですよね。
> デフォルトを打刻するにしておいて、打刻しない場合のみ指定する、
> ということにしておく手も考えられますが。
>
> ご意見などいただけましたら幸いです。
> -- 
> 安藤慶昭＠独立行政法人産業技術総合研究所 研究員
>                  知能システム研究部門 統合知能研究グループ
>                  〒305-8568 茨城県つくば市梅園 
> 1-1-1 中央第2
>                  TEL: 029-861-5981 FAX: 029-862-6631
>                  n-ando ＠ aist.go.jp, n-ando ＠ ieee.org
>

------------------------------------------------------------
産業技術総合研究所   知能システム研究部門　インタラク 
ションモデリングG
主任研究員 原  功 <Isao-Hara ＠ aist.go.jp>
Isao HARA, Senior Researcher, ISRI, ,AIST,Japan
TEL: +81-29-861-5973       FAX: +81-29-862-6631