産総研のジェフです。

問題はデータ型が多いということではないと思います。

本当の問題はインターフェースレベルでインターフェースを指定していません。インターフェースをデータ型レベル（いわゆるポートを個別に指定していること）で指定すると、細かいことで細かい異なりになると思います。

「アームコンポーネントはこの三つのポートで、ポートはこのデータ型を使う」のような指定がもっと互換性ができるでしょうかな。

2014-01-27 Kei Okada

> 岡田です．
>
> お世話になります．
> いまさらですが，僕も感覚的には様々なデータ型を許すと結局データ型間の変換が面倒になる，
> あるいは，変換時にバグが生じる等のデメリットがあり，どれかのデータ型に固定するのがいいと
> 思っているんですが，他の方々の意見にあるように，それぞれ常識として思っているデータ型が違う
> ので，難しいという事だと思います．
>
> とうことで，データ間型の変換を簡単にする，あるいは，バグをなくすために変換の関数を用意するか，
> 変換するコンポーネントを用意するとか，そういうことがあるといいかなと思ったんですが，いかがでしょうか．
>
>
>
>
>
> 2014/1/26 Ando Noriaki :
> > OpenRTM-users MLの皆様
> >
> > 産総研 安藤です
> >
> > 先日東京大学の野沢さんからご提案があり、RTM国際標準化委員会で承認された
> > クオータニオンのデータ型ですが、OpenRTM-aistのExtendedDataTypes.idlに
> > 追加したことをお知らせいたします。
> > ＃ 現在のところtrunkに追加しております。インターフェースが変更となるので
> > ＃1.1のブランチにはマージしておりません。
> >
> > 前回の委員会で再提案となったロボットアームインターフェース仕様などについても
> > 引き続きご議論いただければと思います。
> > 次回のRTM標準化委員会は4月10日の予定です。よろしくお願いいたします。
> >
> >
> >
> > Index: src/lib/rtm/idl/ExtendedDataTypes.idl
> > ===================================================================
> > --- src/lib/rtm/idl/ExtendedDataTypes.idl (リビジョン 2400)
> > +++ src/lib/rtm/idl/ExtendedDataTypes.idl (リビジョン 2401)
> > @@ -694,6 +694,28 @@
> > Time tm;
> > OAP data;
> > };
> > +
> > + /*!
> > + * @struct Quaternion
> > + * @brief Data type for Quaternion
> > + */
> > + struct Quaternion
> > + {
> > + double x;
> > + double y;
> > + double z;
> > + double w;
> > + };
> > +
> > + /*!
> > + * @struct TimedQuaternion
> > + * @brief Timed version data type for Quaternion
> > + */
> > + struct TimedQuaternion
> > + {
> > + Time tm;
> > + Quaternion data;
> > + };
> > };
> >
> > #endif // ExtendedDataTypes_idl
> >
> > 2013年12月25日 23:17 Shunichi Nozawa :
> >> 東京大学の野沢です。
> >>
> >> クォータニオンに関して、大変遅ればせながら返信させていただきたく存じます。
> >>
> >>
> >> 姿勢表現に関しては、末広先生ご指摘の通り
> >> 既存のOrientation3D、Pose3Dでは混乱が多く問題だと思います。
> >>
> >> 一方姿勢表現としてのクォータニオンの導入は、
> >> 私が提案者でもありぜひ採用いただけますと助かります。
> >>
> >> メリットとしては関谷様ご指摘の
> >>
> >>> 1．4要素なので，回転行列（3x3）に比べ，通信量・メモリ使用量が少ない
> >>> 2．オイラー角のように特異点がない
> >>> 3. 回転を積み重ねていった場合の誤差が少ない（正規化が可能）
> >>
> >> と同様のことを考えておりました。
> >>
> >> 一方、議論されているデメリットとしては、
> >> 1. 内部で3x3行列を使用している場合、変換が必要
> >> 2. 仮にクォータニオン・3x3行列を採用する場合、
> >> 同じ状態を表すのに複数のデータ型をもつことになる
> >> などがあるように思います。
> >>
> >> こちらに関して意見を述べさせていただきますと、
> >>
> >>> でも，多くの場合，行列に変換してから処理することが多いと
> >>> 想像するのですがいかがでしょうか．
> >>
> >> オイラー角・3x3行列・クォータニオンのどれがコード内で
> >> 用いられているか、客観的に判断しづらいところがあると考えております。
> >> 実際、私が直近でよく目にするコードでは、クォータニオンがかなり使われております。
> >>
> >> また、
> >>
> >>> この得失を比較して，データは9つになるけど行列の方が
> >>> 汎用性が高いのでデータ交換用には良いのではないかと
> >>> 考えているのですがいかがでしょうか？
> >>
> >> オイラー角でなければ、3x3行列同様クォータニオンも
> >> 表現上の特異点がない点で汎用性は高いと思います。
> >>
> >> データ型の乱立は問題ではありますが、関谷様・ジェフ様ご指摘のとおり
> >> いくつかの基本的な型を用意しておくと、かえって独自型を
> >> 個々人が定義することが避けられ、混乱がないと考えております。
> >>
> >>
> >> 以上を考慮した私の意見としては、
> >> (a) 今回の件では3x3行列とクォータニオン（もしかしたらその他もありえますが）で
> >> どちらも広く使われていると思いますので、複数が採用するのはいかがでしょうか。
> >> (b) また、その際に他の一切のOpenRTM以外のライブラリに依存することなく
> >> それらの間の変換ができることが重要に思います。
> >> OpenHRP3を拝見したところ
> >>
> https://openrtp.org/svn/hrg/openhrp/3.1/trunk/hrplib/hrpUtil/Eigen3d.cpp
> >> 姿勢表現間での変換関数を用意しているようです。
> >> 演算までする必要なく、変換のみで大丈夫かと思いますが、
> >> こういったものをOpenRTMの中に取り込んでいくこともご検討いただきたく存じます。
> >> (いれるとすればcoilなどになりますでしょうか)
> >>
> >> となります。
> >> 以上、ご検討いただけますと幸いです。
> >>
> >> 2013年11月22日 16:51 Makoto Sekiya :
> >>> 末廣先生
> >>>
> >>> 本田技術研究所 関谷です。
> >>>
> >>> クオータニオンデータ型は必要だと思います。
> >>> 弊社では過去，姿勢表現に回転行列を用いていましたが
> >>> 下記の理由から現在ではクオータニオンに統一しています。
> >>>
> >>> 1．4要素なので，回転行列（3x3）に比べ，通信量・メモリ使用量が少ない
> >>> 2．オイラー角のように特異点がない
> >>> 3. 回転を積み重ねていった場合の誤差が少ない（正規化が可能）
> >>>
> >>> また，私どももExtendedDataTypes.idlを参考にクオータニオンデータ型を定義
> >>> しており，それは岡田先生の提案と同様の表現となっております。
> >>>
> >>> 少なくともよく知られたデータ型に関しては，データの要素・並び順などの標準
> >>> があると独自型の乱立を防ぐことができると思います。
> >>>
> >>> よろしくお願いします。
> >>>
> >>> --
> >>> 関谷 眞
> >>> 株式会社 本田技術研究所 基礎技術研究センター
> >>> 第5研究室 第２ブロック
> >>> 351-0188 埼玉県和光市本町8-1
> >>> tel: (048)461-2511 代表
> >>> mail: Makoto_Sekiya@n.f.rd.honda.co.jp
> >>>
> >>> _______________________________________________
> >>> 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
> > _______________________________________________
> > 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
>