末廣様

産総研 ジェフです。

2013/11/20 ts

> (1) クオータニオンデータ型は不要ではないでしょうか．
> この提案は一般のクオータニオンではなく姿勢表現のためのものと
> 理解しています（これが誤解でしたらご指摘ください）．
> クオータニオンが姿勢を表現するのに便利であることは理解しています．
> しかし，データ交換用の表現として便利かどうか疑問があります．
>

必要だと思います。全ロボットシステムの中で、角度はすべてクオータニオンにするとデータ型変換が減るはずですし、誤解が原因のバグも少なくなるはずですし。

コンポーネントがかなり大きかったら、流れているところは少ないかもしれませんが、コンポーネントが小さくて例えばナビゲーションシステムはコンポジットコンポーネントで作られたら、クオータニオンのデータ型があると便利で安心だと思います。

> (2) 同様に現存のOrientation3D型も不要ではないかと思います．
> このOrientation3Dは，rpyで表現されていますが，
> それぞれがどの軸まわりか常に混乱が伴うものです．
> その合意が取れれば人間にとって分かりやすいものではありますが，
> データ交換用の表現として便利かどうか同様に疑問があります．
>

Orientation3Dのメンバーの名前は編集が必要だと私も思います。

> (3)多くのプログラムで利用するときに結局，行列を使いませんか？
> クオータニオンは演算ができますが，rpyは演算には全く不向きです．
> そういう意味ではクオータニオンの方がましですね．
> でも，多くの場合，行列に変換してから処理することが多いと
> 想像するのですがいかがでしょうか．
> それならば3x3の行列表現で統一した方が良いような気がします．
> ここで合意が取れそうならばその線で新たな提案をするのが
> 良いのではないでしょうか．
>

行列はよく使われているなら、そのためのデータ型も提案した方がいいと思います。しかし、行列もクオータニオンも同時にOpenRTMに存在できない理由にならないと思います。両方があると、コンポーネント開発者は自分の要求によって適切なデータ型が使えて、他の開発者はそのデータ型が分かります。

以上、よろしくお願いします。

金広＠産総研です。

＞産総研ジェフさん、

ExtendedDataTypes.idlのデータ型はPlayerのデータ型を参考にして定義した、と
以前どなかかから聞いてような覚えがあります。
正しかったでしょうか？その場合PlayerでもVelocity3D（に対応する）データ型の
中身は同様なのでしょうか？

2013/11/20 ts :
> 皆様，
>
> 電通大　末廣です．SpatialVelocityにかんしてです．
>
> ExtendedDataTypes.idlには，Velocity3Dがあります．
> でもこれは使いものにならないと思います．
> vx, vy, vzの並進速度と並べて，
> rpyの速度として，vr, vp, vaを定義していますが
> この使い道はあるのでしょうか？
> rpyに関しては3軸ジンバルの各モータ速度を制御する
> というイメージでしょうか？かなり特殊な気がします．
>
> 今回提案のSpatialVelocityで使われている並進だけの
> Velocity3Dの方が分かりやすい気がします．
>
> また一方で，AngularVelocity3Dというのもあります．
> 説明が各座標軸周りの速度ということで多少意味があやしいのですが
> 角速度のx,y,z軸成分というのであれば，今回提案の
> SpatialVelocityで使われているAngularVelocity3Dと同じものです．
>
> 個人的には，今回の提案のものの方が現存のものより
> すぐれていると思います．
>
> 他の論点としては，
> ・順番は，回転，並進で良いか？
> structなので順番は関係ないとも言えますが
> 　Wrenchは力，トルクの順です．
> ・速度，角速度はそれぞれVector3Dで良いのではないか．
> 　そうすればVelocity3Dを二つを合わせたものに使える
> ・速度と角速度を並べた6つ組みベクトルという手はないか
> 　ベクトルの方がヤコビアン系の演算のときに便利では？
> 　でもWrenchとの対応は2つに分けた方がきれいかな．
> ・名前はこれで良いだろうか
> などがあるような気がします．
>
> 皆様，ご議論よろしくお願いします．
>
>
> (2013/11/18 18:14), kanehirofmo@nedo.go.jp wrote:
>> OpenRTMユーザーの皆様　←　NEDO金広
>>
>> OpenRTM-aistがBasicDataTypes.idl等で定義しているデータ型やNEDO知能化
>> プロジェクトで策定した共通インタフェースに関して、時折本MLに変更の提案
>> がなされることがありました。その際に提案に対する議論はML上で行われるも
>> のの、最終的にOpenRTM-aistの公式仕様として採用するか否かを決定するプロ
>> セスがはっきりしていなかったため、結論がでないままに忘れられてしまった
>> 案件もあったかと思います。
>>
>> そこで、添付の「RTM関連仕様の提案プロセス（案）r3.docx」に記載のプロセス
>> を経ることで、OpenRTM-aistの公式仕様として採用するということに出来ないか、
>> RTミドルウエア国際標準化調査専門委員会に提案させて頂き、12月26日に開催
>> される次回委員会で審議して頂くこととなりました。
>>
>> 今回、正式運用前ではございますが、本提案プロセスの試運転を開始し、12月
>> 26日の委員会で提案プロセスの案の審議と同時に、それまでに提出された提案
>> に対する審議も行って頂けることとなりましたのでお知らせ致します。
>>
>> 埼玉大琴坂先生、東大岡田先生にご協力頂き、4件のご提案を頂きましたので、
>> これらのご提案に対する議論をお願い致します。また、他にもご提案頂ける案件
>> がございましたら積極的にご提案頂けますようお願い致します（案では議論の期
>> 間を1ヶ月以上設けることとしておりますので、次回委員会で審議を受けるには
>> 遅くとも11月25日までにご提案頂く必要がございますのでご注意下さい）。
>>
>> 以上よろしくお願い致します。
>>

末廣様

産総研　ジェフです。

On 21/11/13 08:07, ts wrote:
> クオータニオン，SpatialVelocity, Wrench，既存の3DＸＸ型．
> 個別に考えるのではなく，3次元剛体力学系または
> 3次元座標系としてまとめて考えるべき問題ではないか
> という気がしてきました．

このように考えることが正しいと思います。一緒に使うデータ型は一緒に考える
べきですね。

_______________________________________________
openrtm-users mailing list
openrtm-users@openrtm.org
http://www.openrtm.org/mailman/listinfo/openrtm-users

金広様

東京大学の野沢です。

> 仕様の書き方に関して：
> 岡田先生、野沢さんから頂いた提案3件に関してですが、コメントをつける必要があるの
> では無いでしょうか。少なくとも単位は明らかにしておかないと誤解が生じる可能性があ
> ると思います。

おっしゃる通りです。大変失礼しました。

Wrench, SpatialVelocityについて、
コメントを付記しますと下記のようになります。

なお、以下では提案書から2点、
1. WrenchとSpatialvelocityの順番をあわせる
2. Wrenchを、WrenchとTimedWrenchにする
と変更を加えております。

1. は これまでのメーリングリストで

> クオータニオン，SpatialVelocity, Wrench，既存の3DＸＸ型．
> 個別に考えるのではなく，3次元剛体力学系または
> 3次元座標系としてまとめて考えるべき問題ではないか
> という気がしてきました．

という末廣先生のコメントを反映させ、
WrenchとSpatialvelocityの順番をあわせております。
回転並進どちらの順番か悩ましいですが、
以下では回転->並進としております。

2.は、提案書の「特記事項」記載のご指摘のを反映し、
既存のセンサ等のデータ型がTimedとそうでないものを
定義している方法を踏襲しております。

Wrenchに関しては

/*!
* @struct Wrench
* @brief 3D cartesian torque and force.
*/
struct Wrench
{
/// 3D Torque in newton meter
Vector3D torque;
/// 3D Force in newton
Vector3D force;
};

/*!
* @struct TimedWrench
* @brief Time-stamped version of Wrench.
*/
struct TimedWrench
{
Time tm;
Wrench data;
};

SpacialVelocityについては
/*!
* @struct SpatialVelocity
* @brief 3D cartesian angular velocity and velocity.
*/
struct SpatialVelocity
{
/// 3D angular velocity in radian per second
AngularVeclotity3D omega;
/// 3D angular velocity in meter per second
Veclotity3D vel;
};

/*!
* @struct TimedSpatialVelocity
* @brief Time-stamped version of SpatialVelocity.
*/
struct TimedSpatialVelocity
{
Time tm;
SpatialVelocity data;
};

よろしくお願い申し上げます。

2013年12月2日 17:49 Fumio KANEHIRO :
> 金広＠産総研（元NEDO）です。
>
> 遅ればせながら、コメントさせて頂きます。
>
> 仕様の書き方に関して：
> 岡田先生、野沢さんから頂いた提案3件に関してですが、コメントをつける必要があるの
> では無いでしょうか。少なくとも単位は明らかにしておかないと誤解が生じる可能性があ
> ると思います。
>
> クオータニオン追加の是非に関して：
> コンポーネント同士を容易に接続できるようにするためには、同じものに対する表現方法は
> 1種類にしておくべきだと思います。ただ、その1種類をどれにするかに関しては、本MLで
> も異なる意見が挙がっているようになかなか全員が納得できる解がないようです。関谷さん
> が言われるように似て非なるクオータニオンの定義が何種類も現れることがないように、
> クオータニオンならこれ、と決めておくのが現実的な解かもしれません。
>
> 議論の範囲について：
> 単位系をどうするか、後方互換性の維持をどうするかなど、提案の内容の範囲を大きく超えた
> 議論も起きているようです。議論していただくのは大変結構なのですが、提案の範囲を大きく
> 越えてしまうと、提案者がまとめるのも大変ですし、結論自体中々でないと思いますので、
> そちらの議論は別途続けて頂いて、適当なタイミングで別途提案とする、提案済みの内容に関
> してはある程度提案の内容にフォーカスを絞って議論して頂けますと助かります。
>
>
> 2013/11/18 :
>> OpenRTMユーザーの皆様　←　NEDO金広
>>
>> OpenRTM-aistがBasicDataTypes.idl等で定義しているデータ型やNEDO知能化
>> プロジェクトで策定した共通インタフェースに関して、時折本MLに変更の提案
>> がなされることがありました。その際に提案に対する議論はML上で行われるも
>> のの、最終的にOpenRTM-aistの公式仕様として採用するか否かを決定するプロ
>> セスがはっきりしていなかったため、結論がでないままに忘れられてしまった
>> 案件もあったかと思います。
>>
>> そこで、添付の「RTM関連仕様の提案プロセス（案）r3.docx」に記載のプロセス
>> を経ることで、OpenRTM-aistの公式仕様として採用するということに出来ないか、
>> RTミドルウエア国際標準化調査専門委員会に提案させて頂き、12月26日に開催
>> される次回委員会で審議して頂くこととなりました。
>>
>> 今回、正式運用前ではございますが、本提案プロセスの試運転を開始し、12月
>> 26日の委員会で提案プロセスの案の審議と同時に、それまでに提出された提案
>> に対する審議も行って頂けることとなりましたのでお知らせ致します。
>>
>> 埼玉大琴坂先生、東大岡田先生にご協力頂き、4件のご提案を頂きましたので、
>> これらのご提案に対する議論をお願い致します。また、他にもご提案頂ける案件
>> がございましたら積極的にご提案頂けますようお願い致します（案では議論の期
>> 間を1ヶ月以上設けることとしておりますので、次回委員会で審議を受けるには
>> 遅くとも11月25日までにご提案頂く必要がございますのでご注意下さい）。
>>
>> 以上よろしくお願い致します。
>>