ロボット、千葉ロッテマリーンズについていいかげんなことを書きます。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
前回アームロボットの制御について述べたので、いよいよRTCの設計に取り掛かりたいと思います。
その前にこういう系のRTCを設計するときには共通I/F仕様書を読んでおきましょう。
とりあえず使いそうな関数を抜き出してみます。
ManipulatorCommonInterface_MiddleLevel.idl
closeGripper
getBaseOffset
getFeedbackPosCartesian
getMaxSpeedCartesian
getMaxSpeedJoint
getSoftLimitCartesian
moveGripper
moveLinearCartesianAbs
moveLinearCartesianRel
movePTPJointAbs
movePTPJointRel
openGripper
pause
resume
stop
setBaseOffset
setMaxSpeedCartesian
setMaxSpeedJoint
setSoftLimitCartesian
setHome
getHome
goHome
ManipulatorCommonInterface_Common.idl
clearAlarms
getActiveAlarm
getFeedbackPosJoint
getManipInfo
getSoftLimitJoint
getState
servoOFF
servoON
setSoftLimitJoint
こんな所だろうか？
次にRTCをどう分割するかを考えます。
前回述べた制御を分けてみると以下のようになると思います。
1～4で4つのRTC、5をモーター4個分の計8つのRTCを作るのだけは絶対にやめてください。
オーバーヘッドもそうですが、細分化しすぎると使いづらいだけです。
rtshellで自動接続、複合コンポーネント化すれば見かけ上単一のRTCと同じように使用できますが、例えば1のRTCだけ入れ替えたいとか思った時に他の7つのRTCを起動しなければならないため非常に面倒です。それに細分化しすぎると各RTCがどのような機能なのか理解するのが難しくなります。
特にSysmlで設計する場合には注意が必要です。
例えば以下のようにシステムを設計したとします。
このブロックを全てRTCに割り当てて実装した場合、非常に使いづらいものが出来あがるので注意してください。
余談はこれぐらいにしておいてRTCの設計に取り掛かりたいと思います。
目標先端位置指令を行うRTCは独立しておくべきだと思います。
GUI、もしくは何らかのデバイスで位置を指示するとか、あるいはセンサの情報から位置を計算するとか置き換えが効きやすいので分離しておきます。
一旦目標位置を指令したらその目標位置に到達するように補間軌道を生成するので、連続的に目標位置を送ることも少ないと思います。
迷うのが軌道生成と関節角度算出のRTCですが、僕は同じRTCにしておきます。
まあ確かにどちらも置き換えが効きそうではあるのですが、アームのリンク長さとかパラメータを共有させるのが面倒になるのであまり気が進みません。連続的にデータを送るわけだから、オーバーヘッドの影響も露骨になってくるでしょうし。
関節角度をモーターの角度への変換とモータ制御は同一のRTCで実装します。
どうやってサーボモーターを制御するかは自由度があったほうが良いのかもしれないですけど、それだったら自分でソースコード書いたらいいだろと思っているので完全に例のロボットアームの制御専用のRTCにします。
そして迷うのは2、3、4、5の機能を単一のRTCにするか、あるいは2つのRTCにするかですね。
一見して関節角度算出の部分は再利用性は低いように見えるのですが、この手の垂直多関節ロボットなんてたくさんあるだろうし、分離も考えた方が良いかもしれないです。あと、シミュレーションにも応用できるかもしれないので便利かもしれないですね。
4、5のRTCも別の方法で制御する場合、他のRTCと接続する事もあるかもしれないです。
いやでも実装が面倒くさい、オーバーヘッドが大きい、システムの見通しが悪くなる、使用する際の手間が増えると言ったデメリットを上回るメリットがあるかと言われれば微妙です。
最終的にはRT-Preemptでリアルタイム制御をしたいと思っているのであまり分離はしたくないです。rtcdで起動、複合コンポーネント化が地味に面倒でデバッグが面倒になるので気が進みません。リアルタイムシステムでRTCを分ける事自体間違いではないかと思っているのですが、どうでしょうね？
そもそも4、5の機能はそんなに複雑なプログラムにはならないと思うので、わざわざ分離する必要もないかもしれないです。
1、2、3、4を単一のRTCで実装すると言う事になりましたが、何だか微妙です。
多分単一のRTCであれば使ったことない人が最初に使う分には使いやすいと思います。
ただ確かに応用は効きにくいので、分離すべきか。
さて単一のRTCで実装するとして、どのようなデータポート、サービスポート、アクティビティ、コンフィギュレーションパラメータにするかを考えます。
まずデータポートとしては現在の関節角度(TimedDoubleSeq型)のアウトポートぐらいですかね？ただ、関節角度のアウトポートに接続する時は注意が必要でSubscription Typeを変更するか、あるいはPULL型にする必要があります。
サービスポートは共通インターフェースを使います。
コンフィギュレーションパラメータはRTCを完全にあのアーム専用と割り切ってしまえば長さが変わる事なんてそうないだろうし、そんな大量にはならないと思います。いや別に多いのが悪いとは思っていませんけど。
とりあえず操作用GUIを作ってみました。
ここからダウンロードできます。
このRTCは以前作成したゲーム作成ツール上で動作します。
今の所凄まじく3Dモデルがしょぼい、歪ですが、これは仮の姿です。
後でメタセコイアで作成したモデルを変換して読み込ませます。
それから昨日作成したシミュレータをコンポーネント化しました。
GUIのRTCと接続して使ってください。
ここまでやっておいて今更ですけど、ロボットを持っていません。
持っている人がいれば実装してください。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
その前にこういう系のRTCを設計するときには共通I/F仕様書を読んでおきましょう。
とりあえず使いそうな関数を抜き出してみます。
ManipulatorCommonInterface_MiddleLevel.idl
closeGripper
getBaseOffset
getFeedbackPosCartesian
getMaxSpeedCartesian
getMaxSpeedJoint
getSoftLimitCartesian
moveGripper
moveLinearCartesianAbs
moveLinearCartesianRel
movePTPJointAbs
movePTPJointRel
openGripper
pause
resume
stop
setBaseOffset
setMaxSpeedCartesian
setMaxSpeedJoint
setSoftLimitCartesian
setHome
getHome
goHome
ManipulatorCommonInterface_Common.idl
clearAlarms
getActiveAlarm
getFeedbackPosJoint
getManipInfo
getSoftLimitJoint
getState
servoOFF
servoON
setSoftLimitJoint
こんな所だろうか？
次にRTCをどう分割するかを考えます。
前回述べた制御を分けてみると以下のようになると思います。
- 目標先端位置指令
- 軌道生成
- 関節角速度算出
- 関節角度をモーターの角度に変換
- モーター制御
1～4で4つのRTC、5をモーター4個分の計8つのRTCを作るのだけは絶対にやめてください。
オーバーヘッドもそうですが、細分化しすぎると使いづらいだけです。
rtshellで自動接続、複合コンポーネント化すれば見かけ上単一のRTCと同じように使用できますが、例えば1のRTCだけ入れ替えたいとか思った時に他の7つのRTCを起動しなければならないため非常に面倒です。それに細分化しすぎると各RTCがどのような機能なのか理解するのが難しくなります。
特にSysmlで設計する場合には注意が必要です。
例えば以下のようにシステムを設計したとします。
このブロックを全てRTCに割り当てて実装した場合、非常に使いづらいものが出来あがるので注意してください。
余談はこれぐらいにしておいてRTCの設計に取り掛かりたいと思います。
目標先端位置指令を行うRTCは独立しておくべきだと思います。
GUI、もしくは何らかのデバイスで位置を指示するとか、あるいはセンサの情報から位置を計算するとか置き換えが効きやすいので分離しておきます。
一旦目標位置を指令したらその目標位置に到達するように補間軌道を生成するので、連続的に目標位置を送ることも少ないと思います。
迷うのが軌道生成と関節角度算出のRTCですが、僕は同じRTCにしておきます。
まあ確かにどちらも置き換えが効きそうではあるのですが、アームのリンク長さとかパラメータを共有させるのが面倒になるのであまり気が進みません。連続的にデータを送るわけだから、オーバーヘッドの影響も露骨になってくるでしょうし。
関節角度をモーターの角度への変換とモータ制御は同一のRTCで実装します。
どうやってサーボモーターを制御するかは自由度があったほうが良いのかもしれないですけど、それだったら自分でソースコード書いたらいいだろと思っているので完全に例のロボットアームの制御専用のRTCにします。
そして迷うのは2、3、4、5の機能を単一のRTCにするか、あるいは2つのRTCにするかですね。
一見して関節角度算出の部分は再利用性は低いように見えるのですが、この手の垂直多関節ロボットなんてたくさんあるだろうし、分離も考えた方が良いかもしれないです。あと、シミュレーションにも応用できるかもしれないので便利かもしれないですね。
4、5のRTCも別の方法で制御する場合、他のRTCと接続する事もあるかもしれないです。
いやでも実装が面倒くさい、オーバーヘッドが大きい、システムの見通しが悪くなる、使用する際の手間が増えると言ったデメリットを上回るメリットがあるかと言われれば微妙です。
最終的にはRT-Preemptでリアルタイム制御をしたいと思っているのであまり分離はしたくないです。rtcdで起動、複合コンポーネント化が地味に面倒でデバッグが面倒になるので気が進みません。リアルタイムシステムでRTCを分ける事自体間違いではないかと思っているのですが、どうでしょうね？
そもそも4、5の機能はそんなに複雑なプログラムにはならないと思うので、わざわざ分離する必要もないかもしれないです。
1、2、3、4を単一のRTCで実装すると言う事になりましたが、何だか微妙です。
多分単一のRTCであれば使ったことない人が最初に使う分には使いやすいと思います。
ただ確かに応用は効きにくいので、分離すべきか。
さて単一のRTCで実装するとして、どのようなデータポート、サービスポート、アクティビティ、コンフィギュレーションパラメータにするかを考えます。
まずデータポートとしては現在の関節角度(TimedDoubleSeq型)のアウトポートぐらいですかね？ただ、関節角度のアウトポートに接続する時は注意が必要でSubscription Typeを変更するか、あるいはPULL型にする必要があります。
サービスポートは共通インターフェースを使います。
コンフィギュレーションパラメータはRTCを完全にあのアーム専用と割り切ってしまえば長さが変わる事なんてそうないだろうし、そんな大量にはならないと思います。いや別に多いのが悪いとは思っていませんけど。
とりあえず操作用GUIを作ってみました。
ここからダウンロードできます。
このRTCは以前作成したゲーム作成ツール上で動作します。
今の所凄まじく3Dモデルがしょぼい、歪ですが、これは仮の姿です。
後でメタセコイアで作成したモデルを変換して読み込ませます。
それから昨日作成したシミュレータをコンポーネント化しました。
GUIのRTCと接続して使ってください。
ここまでやっておいて今更ですけど、ロボットを持っていません。
持っている人がいれば実装してください。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
PR
この記事にコメントする
