菅様,OpenRTM-usersの皆様
お世話になっております。
埼玉大学設計工学研究室の藤間です。
まず、今回のロボットアーム制御機能共通I/Fの改版の提案では、低レベルRTCの
仕様変更は行わず、中レベルRTCの仕様変更のみを考えてご提案させていただき
ました。
ただ、現在の低レベルRTCの仕様は議論する必要があると考えておりますので、
議論の方は引き続きお願い致します。
菅様からご指摘がありました、
・単位系をradianとm表記
・RETURN_IDにNOT_IMPLEMENTEDを追加、enumをIDLファイルに追加
につきましては、私も同感です。
しかし、単位系の変更によって数少ない実装であるPA10とMELFAのRTCが利用でき
なくなり、後方互換性が失われるという問題がありますが、その点は皆様どのよ
うにお考えでしょうか。
私は、PA10とMELFAのRTCを改版した共通I/Fに対応していただけるようでしたら、
改版案に含めるべきであると考えております。
また、第1.0版のインタフェースとの誤接続を防ぐために、インタフェース名を
・ManipulatorCommonInterface_Middle_1_1
に変更するべきだと考えております。
次に、低レベルRTCの仕様変更の部分ですが、
3.1項のsetTargetJointVelocityで設定した値を読むgetTargetJointVelocityや3.
2項の角度指令を相対値で行うmoveJointPosRelも追加するべきでしょうか。
また、3.2項のsetTargetJointPosAbsとは、中レベルインタフェースの
movePTPJointAbsとは異なり、全ての軸の動作が同時に開始・終了するのではな
く、各軸がsetTargetJointVelocityで指定された速度で目標位置まで動作すると
いう認識でよろしいのでしょうか。
その認識で合っていれば、名称はmoveを用いてmoveJointPosAbsなどの方が適切
かと思うのですが、いかがでしょうか。
最後に、3.3項の
・共通インタフェースレベルにgetDHparameterを追加
に関してですが、このコマンドがあった方が便利であるのは同感ですが、ロボッ
トの機構によってはDHパラメータが定義できないもの(私の研究室で利用してい
るMELFAも定義できません)も存在するため、方法を検討する必要があると思い、
今回の提案には含めない方向で考えています。
改訂したIDLファイルを添付させていただきます。
OpenRTM-usersの皆様、どうぞよろしくお願いいたします。
ML皆様，
株式会社SSRの菅です．お世話になります．
アームの共通インターフェース改訂案おまとめいただきありがとうございます．
いつくか意見を述べさせてください．
＞皆様
現在議論されいてる共通インターフェースは下記の箇所からダウンロードできます．
http://www.openrtm.org/openrtm/ja/project/Recommendation_CommonIF
私も不勉強ですので，お知恵を頂ければと思います．
私は，某社のロボットに共通インターフェースを実装した経験から，述べさせていただきます．
１．単位について
１．１ 角度の表現
角度表現については，全面的にRadian表記に変更して頂きたいと思っています．
演算を行うたびにradianに変換するのがばかばかしいと感じています．
１．２ 距離の表現
単位としてメートル表記として頂きたいです．移動系のインターフェースと連携させるときに不便です．（移動側をmmにする手もありますが，統一したほうがいい，という議論はあっても良いかと）
２．RETURN_IDについて
あらかじめ定義しているRETURN_IDの値（表４．４）に大して，
NOT_IMPLEMENTEDを許してください．
これにより，後述するような研究用ロボットとして重要な機能に対して，
実装できない産業用ロボットアームなどでも，
共通インターフェースを利用することが出来ますし，
様々なレベルのユーザが利用できるインターフェースになるかと思います．
（マニュアル内のIDLの例に，これらの値のenumが無いのが気になります）
３．低レベルインターフェースについて
ロボットアーム共通インターフェースは，２つのレベルで定義されており，低レベルは運動学などが入らない，ロボットアームを直接動作させるインターフェースになっています．
このインターフェースに対して，中レベルからアクセスすることで，運動学部分を切り離す設計になっていますが，論理的に破綻していると思っています．
３．１ 低レベルインターフェースに速度指令が無い
直線軌道が描けませんので，速度指令についてはご勘案いただきたいです．
３．２ 角度指令だけデータポートになっている
速度指令とともにデータポートで上位と受け渡す仕様は悪くないと思いますが，
出来れば，
setTargetJointPosAbsや，setTargetJointVelocity
のようなインターフェースを用意して頂きたいです．両方あってもかまいません
サービスポートか，データポートか？という議論に対しては，
この共通インターフェースレベルではサービスポートの方が優位だと感じています．
C++やPythonのAPIに共通インターフェースを実装することが出来るようになります．
また，それがロボットの要求仕様にもなります．便利です．
３．３ D-Hパラメータを取得できるインターフェース
共通レベルのインターフェースに，D-Hパラメータを得るためのインターフェースを桶真千kでしょうか？これを呼べば中レベルがコンフィグレーションレスになるかと思います．
メーカー名や，マニュピレータの型番よりも重要な情報だと思います．
（現状だと，コンフィグレーションで上位に渡すしか無いのではないでしょうか？）
まずは思いつくところだけ送ります．