RTミドルウエアの産業応用を目的としたロボットアーム制御機能共通I/F拡張の提案
RTミドルウエアの産業応用を目的としたロボットアーム制御機能共通I/F拡張の提案
投稿日時:
月, 2013-11-18 19:39
発表
- SI2013&RTミドルウエアコンテスト2013応募作品
「RTミドルウエアの産業応用を目的としたロボットアーム制御機能共通I/F拡張の提案」
概要
- 現在のロボットアーム制御機能共通インタフェース仕様について、以下の3項目の拡張を行い、仕様書の第1.1版(草案)を作成した。
- 1~3軸の直交座標型,4軸の水平多関節型,5~7軸の垂直多関節型産業用ロボットへの対応
- 円弧補間動作コマンドの追加
- 原点復帰動作コマンドの追加
特徴
- 産業現場で多用されている直交座標型や水平多関節型の産業用ロボットに対応
- シミュレータによって、直交座標型や水平多関節型の産業用ロボットの動作確認が可能
開発環境
- 言語:C++
- OS:Windows7 SP1
- RTミドルウエア(C++):OpenRTM-aist-1.1.0-RELEASE
- 使用ライブラリ:DXライブラリ(ver3.10a)
コンポーネント群
- OperationCommandRTC:拡張した共通I/F仕様に基づく低,中レベル共通コマンドと中レベルモーションコマンドを送信
- RobotSimulatorRTC_1Axis:ヤマハ発動機株式会社製の単軸直交座標型産業用ロボット(T412BK-200)の運動学シミュレータ
- RobotSimulatorRTC_2Axes:ヤマハ発動機株式会社製の2軸直交座標型産業用ロボット(T412BK-200 AND T512BK-100)の運動学シミュレータ
- RobotSimulatorRTC_4Axes:株式会社デンソーウェーブ製の4軸水平多関節型産業用ロボット(HS-4535G)の運動学シミュレータ
- RobotSimulatorRTC_6Axes:三菱電機株式会社製の6軸垂直多関節型産業用ロボット(RV-3SD)の運動学シミュレータ
ダウンロード
ロボットアーム制御機能共通インタフェース仕様書(SI単位系準拠 第1.0版)のダウンロードはこちらから(2014/05/16更新)zipファイル(ver1.1)のダウンロードはこちらから(2013/11/27更新)
- ドキュメント
- ロボットアーム制御機能共通インタフェース仕様書拡張の提案書
- ロボットアーム制御機能共通インタフェース仕様書(1.1版 草案)
- ロボットアーム制御機能共通インタフェース仕様書 改版点のまとめ
- 各RTC操作マニュアル
- ソフトウエア
- 開発したRTC,GUIのソースファイル
- 開発したRTC,GUIのバイナリファイル
発表スライド
ライセンス
本ソフトはMITライセンスのもとで公開されています.ダウンロードしたフォルダ内のLICENSE.txtをお読みください.
また,著作権は埼玉大学設計工学研究室が保有しています.
謝辞
本研究は,独立行政法人新エネルギー・産業技術総合開発機構(NEDO)の支援によって得られた成果です.
ここに,NEDOならびに関係者の方々への感謝の意を表します.
連絡先
- 埼玉大学 工学部 機械工学科
- 設計工学研究室
- 〒338-8570
- 埼玉県さいたま市桜区下大久保255
- URL:http://design.mech.saitama-u.ac.jp/index.html
- E-mail:mailto:openrtm@design.mech.saitama-u.ac.jp
問合先(メールアドレス):
openrtm@design.mech.saitama-u.ac.jp
最終更新日時:
金, 2014-05-16 18:30
コメント
OperationCommandRTC::onExecute()で、
FileName = new char[m_len+1];
とメモリ領域を確保していますが、これが解放(delete)されていないようです。
メモリリークは時としてデバッグ困難な問題を引き起こしますので、 new と delete は必ずセットで使うようにした方がよいと思います。
OperationCommandRTC::ActCommand()ですが、この関数だけで1500行程度あります。 関数分割する等の工夫をした方がよいと思います。
40個以上ある機能をif-else文だけで全部一つの関数内で列挙するのは、 コードの可読性も悪いですし、何よりメンテナンスが大変です。
tmsimiz様
埼玉大学の藤間です。 コメントの方、ありがとうございます。
ご指摘の通り、メモリリークを防ぐためにメモリの解放(delete)を行う仕様に変更しようと思います。 また、仰る通り全オペレーションコマンドを1つの関数内に記述するのはメンテナンスが大変ですので、コマンド毎の分割記述を検討いたします。