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

Yusuke Nakajima y.nakajima ＠ aist.go.jp
2009年 9月 28日 (月) 13:43:10 JST 

安藤様、皆様

産総研の中島です。

現状の仕様であることを了解しました。

私の説明の「唯一」という表現は良くなかったかもしれないので、
少し具体的に追記します。
原さんのセンサーでのイベント発生時刻の説明に近いのですが、
私の方では、移動台車ロボットをRTCで動かす際に、ローカライズ
するために、ある時刻での車輪の「エンコーダ値＋timestamp」を
DataPortで送信し、次のRTCでそのエンコーダ値からオドメトリで
「位置姿勢(X,Y,Theta)＋timestamp(コピー)」を算出し、それを次のRTCに送信
し、速度制御してロボットを動かすという処理を複数のRTC群で行ってますが、
データの中身は違えど同じ「timestamp」に紐づくデータであり、timestampが変
更されてはマズイということで、前回メールの例に書きました。
（唯一という書き方で逆に混乱させてしまい申し訳有りません。）

素人考えで、例えば、送信時に「Time tm」部をチェックして、Nullだったら、
送信時刻を付与し、もし既に何らかの時刻（OpenHRP3側で付けたり、RTC内部で
オリジナルルールに基づいた時刻など）が付与されていれば、そのままいじらず
送信するのはどうかな、と思ってました。

ただし、やはり統一性を考えると良くないのかもしれません。

原さんもお書きのようにヘッダのように別のところに送信時刻を付けるか、
もしくは、仕様通り「tm」部には自動で送信時刻を入れて、イベント発生時刻な
どの意味でのtimestampは別途ユーザが独自型のDataタイプをIDL作って、その中
に「long timestamp_sec」「long timestamp_nsec」宣言して、そこを利用する
などと考えていました。

良案は思い浮かびませんが、仕様が決定されていて、周知されていることが先決
かと思います。


> 安藤様、皆様：
> 
> 産総研の原です。
> 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
> 
> 
> 
> 
>

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