菅様,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
私も不勉強ですので,お知恵を頂ければと思います.
私は,某社のロボットに共通インターフェースを実装した経験から,述べさせていただきます.
1.単位について
1.1 角度の表現
角度表現については,全面的にRadian表記に変更して頂きたいと思っています.
演算を行うたびにradianに変換するのがばかばかしいと感じています.
1.2 距離の表現
単位としてメートル表記として頂きたいです.移動系のインターフェースと連携させるときに不便です.(移動側をmmにする手もありますが,統一したほうがいい,という議論はあっても良いかと)
2.RETURN_IDについて
あらかじめ定義しているRETURN_IDの値(表4.4)に大して,
NOT_IMPLEMENTEDを許してください.
これにより,後述するような研究用ロボットとして重要な機能に対して,
実装できない産業用ロボットアームなどでも,
共通インターフェースを利用することが出来ますし,
様々なレベルのユーザが利用できるインターフェースになるかと思います.
(マニュアル内のIDLの例に,これらの値のenumが無いのが気になります)
3.低レベルインターフェースについて
ロボットアーム共通インターフェースは,2つのレベルで定義されており,低レベルは運動学などが入らない,ロボットアームを直接動作させるインターフェースになっています.
このインターフェースに対して,中レベルからアクセスすることで,運動学部分を切り離す設計になっていますが,論理的に破綻していると思っています.
3.1 低レベルインターフェースに速度指令が無い
直線軌道が描けませんので,速度指令についてはご勘案いただきたいです.
3.2 角度指令だけデータポートになっている
速度指令とともにデータポートで上位と受け渡す仕様は悪くないと思いますが,
出来れば,
setTargetJointPosAbsや,setTargetJointVelocity
のようなインターフェースを用意して頂きたいです.両方あってもかまいません
サービスポートか,データポートか?という議論に対しては,
この共通インターフェースレベルではサービスポートの方が優位だと感じています.
C++やPythonのAPIに共通インターフェースを実装することが出来るようになります.
また,それがロボットの要求仕様にもなります.便利です.
3.3 D-Hパラメータを取得できるインターフェース
共通レベルのインターフェースに,D-Hパラメータを得るためのインターフェースを桶真千kでしょうか?これを呼べば中レベルがコンフィグレーションレスになるかと思います.
メーカー名や,マニュピレータの型番よりも重要な情報だと思います.
(現状だと,コンフィグレーションで上位に渡すしか無いのではないでしょうか?)
まずは思いつくところだけ送ります.