視覚センサの利用 から:
「OpenRTMに付属のIDL」とは、
/usr/include/openrtm-1.1/rtm/idl/InterfaceDataTypes.idl
に含まれるRTC::PointCloud
のことですね?これは標準には含まれていますが、私はこれを使った実装を見たことがありません。それから、1点に48byte(double×6)使っているため、データが大変大きくなってしまします。一方、「OpenRTMの公式ではない古いIDL」とは、RTC:PCLに含まれる
PointCloudTypes::PointCoud
と同じものだと思います。
標準ではないといえ、これにはいくつが実装があり、1点のデータは16byteです。私は、引き続きこちらのデータ型を使った方がいいのではないかと思います。
これについて、私の方でもIDLの内容を見て確認しましたところ、升谷先生のおっしゃることはもっともだと思いました。
確かに標準のRTC::PointCloudのIDLは、問題があるように思います。特に色の情報について、R、G、Bの各成分にそれぞれ64ビットのdouble型を割り当てているのはやりすぎですね。通常は各成分8ビットで計24ビットあれば十分で、3バイトで済むところが24バイトも使うことになってしまいます。頂点情報についても、x、y、zの各成分がdouble型となっていますが、データの精度的にはfloat型で十分かと思います。(計算するときはdoubleの精度が必要になることもあり得るが、元データとしてはfloatで十分かと。)
また、頂点情報に対して常に色情報も付与しなければならないというのも、柔軟性がないですね。色情報は必要なかったり、画像データとして持たせることもあります。この構造だと、そもそも色情報がないデータというのが表現できないように思います。(それか、色の値としてNaNを入れておくとか?でも必要ないデータのために大量のNaNを入れるというのもナンセンスですよね。)また、色情報を入れたとしても、画像データとして表現するのに必要な情報(縦横解像度など)も付与できないので、Kinectのように元が画像データだったとしてもそれを復元できません。
というわけで升谷先生のご指摘を受け、古い方のPointCloudTypes::PointCloud型を今後も使えるようにすることにしました。
これに伴いサンプルも整理しました。
sample/OpenRTM以下に、
- OpenRTM-TankVisionSensors.cnoid
- OpenRTM-TankVisionSensors-NewIDL.cnoid
を用意しました。
1はPointCloudTypes::PointCloud型を、2はRTC::PointCloud型を使用しています。シミュレーションの内容的には同じです。
今回、VisionSensorIoRTCとVisionSensorSubscriberRTCItemを改良し、どちらも両方のIDLに対応できるようにしています。デフォルトではPointCloudTypes::PointCloud型が使われるようになっていて、オプションやプロパティで設定することにより、RTC::PointCloud型も使えるようにしました。
また、BodyRTCItemを使っていた、OpenRTM-TankVisionSensors-OldIDL.cnoidは廃止しました。