ロボット、千葉ロッテマリーンズについていいかげんなことを書きます。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
凄く今更なのですが、Edisonでロボットアームを制御する事に関しては既に別の人がやっています。
どこかで違いを付けないとただの真似になるので何かしなくてはなりません
と言うよりも知らなかっただけですが。
あとこのページの人もアームを動かしているようです。
二番煎じは相当まずいです。正直なところここまでやったことだけでもそれなりに自信があったのですが、全く何の反応もないあたりからまずさが分かると思います。
実はニコニコ動画にも動画を上げていたのですが、僕とは全く関係ないコメントしか付いてません。
言い訳ですけど、ロボットを制御するとして安価に手に入るのは車輪で移動するロボットかアームに限られると思うので被るのは仕方ないと思います。多脚ロボットは高いですからね。
まあ自分のEdison練習用と思ってやっていたのでその辺はこれから考えます。
とりあえず今回の実験で必要な物は3万円ぐらいで揃うのでRTM講習会とかで使ったら面白いかもしれません。
EdisonをArduinoにしてRTnoを使ったら、機能は限定されますが8000円ぐらいは削減できます。
それからサーボモーターではなく内界センサのない普通のモーターで動作するロボットアームにすれば1万円ぐらい削減できます。それでどうやって角度制御するかって？カメラで撮った画像から角度を推定するようなプログラムを作ってください。ちなみに僕は全くどんなプログラムを書けば良いのか知りません。
今回のロボットを動作させるまでの手順を説明すると、
今回は簡単な事しかしていませんが、ロボットを動かす上でシミュレーションは非常に重要です。
そしてシミュレーションで使った制御のプログラムをファイル、ライブラリ、RTCにしてもそのまま使い回せればバグが発生してロボット実機を壊す事もないと言う事です。
まあ今回のロボットはそんなに力が出せないので壊れる事は少ないとは思いますけど。
ただ、どうにもRTCの設計だけは疑問が残っています。
単一のRTCにして良かったのか、2つに分けた方が良かったのか正直分かりません。
詳しい人は教えてください。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
どこかで違いを付けないとただの真似になるので何かしなくてはなりません
と言うよりも知らなかっただけですが。
あとこのページの人もアームを動かしているようです。
二番煎じは相当まずいです。正直なところここまでやったことだけでもそれなりに自信があったのですが、全く何の反応もないあたりからまずさが分かると思います。
実はニコニコ動画にも動画を上げていたのですが、僕とは全く関係ないコメントしか付いてません。
言い訳ですけど、ロボットを制御するとして安価に手に入るのは車輪で移動するロボットかアームに限られると思うので被るのは仕方ないと思います。多脚ロボットは高いですからね。
まあ自分のEdison練習用と思ってやっていたのでその辺はこれから考えます。
とりあえず今回の実験で必要な物は3万円ぐらいで揃うのでRTM講習会とかで使ったら面白いかもしれません。
EdisonをArduinoにしてRTnoを使ったら、機能は限定されますが8000円ぐらいは削減できます。
それからサーボモーターではなく内界センサのない普通のモーターで動作するロボットアームにすれば1万円ぐらい削減できます。それでどうやって角度制御するかって？カメラで撮った画像から角度を推定するようなプログラムを作ってください。ちなみに僕は全くどんなプログラムを書けば良いのか知りません。
今回のロボットを動作させるまでの手順を説明すると、
- Intel Edison kit for Arduinoを購入
- EdisonをYocto Linuxで動作確認
- EdisonでOpenRTM-aist-Pythonの動作確認
- EdisonでOpenRTM-aistの動作確認
- パッケージの不足等の理由でYocto Linuxからubilinuxに変更
- ネームサーバー、RTCの自動起動を実装
- 何かロボットを動かしたいと思ったため、SainSmart製4自由度ロボットアームについて調べる
- 手先位置制御のための数式を導出する
- ODEによりシミュレーションを行う
- RTCの設計を考える
- GUIを制作
- シミュレータをRTC化することによりGUIのRTCで操作できるようにした
- ロボットを購入
- サーボモータの動作確認
- Edisonにロボット制御のRTCを実装
- GUIを改良
- 実験
今回は簡単な事しかしていませんが、ロボットを動かす上でシミュレーションは非常に重要です。
そしてシミュレーションで使った制御のプログラムをファイル、ライブラリ、RTCにしてもそのまま使い回せればバグが発生してロボット実機を壊す事もないと言う事です。
まあ今回のロボットはそんなに力が出せないので壊れる事は少ないとは思いますけど。
ただ、どうにもRTCの設計だけは疑問が残っています。
単一のRTCにして良かったのか、2つに分けた方が良かったのか正直分かりません。
詳しい人は教えてください。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
PR
いよいよ実験します。
いい感じで動作できているようです。
とは言っても動いただけなのでここからどうするかが問題です。
何か変な動きでも良いので特殊な事をしなければ意味がありません。
今日は疲れたのでこれぐらいにしておきます。
アイデアが浮かんだらまた書きます。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
いい感じで動作できているようです。
とは言っても動いただけなのでここからどうするかが問題です。
何か変な動きでも良いので特殊な事をしなければ意味がありません。
今日は疲れたのでこれぐらいにしておきます。
アイデアが浮かんだらまた書きます。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
痛恨のミスをしていた事に気付きました。
手先のモーターがハンドを閉じるためのものだと思っていたのですが、手先を回転させるモーターでした。ひょっとしたら今までで一番アホなミスかもしれないです。
とりあえず今まで作成したシミュレータ、RTCは修正しておきました。
それからGUIを改良しました。
一見して何も変わっていないように見えますが、実はロボットのモデルを変更してあります。
それから例のロボットアームを買ってしまいました。
欲求に負けてしまいました。
何だか仕様書がないのですが大丈夫でしょうか？もちろん僕がロボットを壊すかもしれないと言う意味でですけど。
とりあえずサーボモータの動作確認をしただけです。
後シミュレータ、GUIのモデルの寸法を実機に合わせておきました。仕様書が無いために自分で測った長さなのでかなり適当です。
ここまででやった事は、
EdisonでOpenRTM-aist、OpenRTM-aist-Pythonの動作確認
Edisonでネームサービス、RTCの自動起動を実装
アームの手先位置制御に必要な数式の導出
アームのシミュレーション
アーム操作用GUIの作成
後はEdisonにアーム制御のRTCを実装するだけです。
全然関係ないけど、例のアームの動画を探していたら関連動画で面白い動画を見つけました。
ちょっと手際が良すぎるだろと思いました。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
手先のモーターがハンドを閉じるためのものだと思っていたのですが、手先を回転させるモーターでした。ひょっとしたら今までで一番アホなミスかもしれないです。
とりあえず今まで作成したシミュレータ、RTCは修正しておきました。
それからGUIを改良しました。
一見して何も変わっていないように見えますが、実はロボットのモデルを変更してあります。
それから例のロボットアームを買ってしまいました。
欲求に負けてしまいました。
何だか仕様書がないのですが大丈夫でしょうか？もちろん僕がロボットを壊すかもしれないと言う意味でですけど。
とりあえずサーボモータの動作確認をしただけです。
後シミュレータ、GUIのモデルの寸法を実機に合わせておきました。仕様書が無いために自分で測った長さなのでかなり適当です。
ここまででやった事は、
EdisonでOpenRTM-aist、OpenRTM-aist-Pythonの動作確認
Edisonでネームサービス、RTCの自動起動を実装
アームの手先位置制御に必要な数式の導出
アームのシミュレーション
アーム操作用GUIの作成
後はEdisonにアーム制御のRTCを実装するだけです。
全然関係ないけど、例のアームの動画を探していたら関連動画で面白い動画を見つけました。
ちょっと手際が良すぎるだろと思いました。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
前回アームロボットの制御について述べたので、いよいよ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と接続して使ってください。
ここまでやっておいて今更ですけど、ロボットを持っていません。
持っている人がいれば実装してください。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
さて前回述べた通りSainSmart製4自由度ロボットアームの制御をEdisonでやろうと思います。
と思ったのですが、ロボットアームを持っていません。
動いている動画を見つけたので、どういう動作なのか見てみます。
一見、こんな感じのシリアルリンク機構ですが、
実際はこんな感じです。
本当はM2とM3が重なっていたり、J3とL3が重なっていたりするのですが、図の見やすさからこうしてます。実際は以下のような配置です。
他にも部品がじゃらじゃら付いていますが手先を地面と平行にするためのものだと思います。
一応、座標系は以下のように設定します。
後、モーターの角度はθm1、θm2、θm3とします。
とりあえず逆運動学で手先位置から関節角度、さらにそこからモーターの角度を求めたいのでまずはモーターの角度と関節角度の関係を求めます。
θ1=θm1、θ2=θm2は見たまんまなのですが、θ3が一見すると難しそうです。
と思わせておいて、M2とM3、J3とL3が重なっており、向かい合うリンクの長さが同じ場合は簡単です。
とりあえず、一部だけ抜き出して簡略化してみます。
このように常に向かい合うリンクが平行になるので、θ3はθm3からθm2を引いただけで導出できます。
つまりモーターの角度と関節角度の関係式は以下のようになります。
次に手先位置を関節角度から順運動学で導出します。
計算過程は省きますが以下のようになります。
そしてここから偏微分して手先速度と関節角速度の関係を求め、ヤコビ行列を導出します。
以下のように導出できます。
後は逆ヤコビ行列を導出して手先速度を入力すれば関節角速度が求まります。
次に手先の軌道を考えます。
とりあえず、初期位置と目標位置との距離ST、到達時間T、時間tから以下の式のように三角関数で導出します。
ちなみにこの計算式では以下のような軌道になります 。
急に加減速したら恐いので滑らかな軌道を描くようにしましょう。
この式から先端の目標加速度、速度、位置は以下の式で導出できます。
そして位置誤差のフィードバックを加えて先端指令速度を導出して、そこから関節角速度、関節角度を導出できます。
おそらく角加速度をセンシングする手段はないのでdθhで導出した関節角速度の指令値をそのまま積分します。
これで分解速度制御を行うために必要な数式は一通り導出できたので、ODEでシミュレーションを行います。ChoreonoidとかV-REPとか使わないのかよとか言われそうですが、あまりそういう気分でもないのでやめておきます。そりゃできればあの機構でシミュレーションをやりたいのですが、難しいので簡略化したモデルでシミュレーションしています。
動画は作っていないので、見たい人はここからシミュレーションのソースコードと実行ファイルをダウンロードしてください。
目標位置に手先が滑らかに移動できています。
と言うか、僕は何で持ってもいないロボットの制御則を考えているのでしょうね？
何だか悲しくなってきました。
次はここからどのようにRTCを設計するかを考えてみます。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
と思ったのですが、ロボットアームを持っていません。
動いている動画を見つけたので、どういう動作なのか見てみます。
一見、こんな感じのシリアルリンク機構ですが、
実際はこんな感じです。
本当はM2とM3が重なっていたり、J3とL3が重なっていたりするのですが、図の見やすさからこうしてます。実際は以下のような配置です。
他にも部品がじゃらじゃら付いていますが手先を地面と平行にするためのものだと思います。
一応、座標系は以下のように設定します。
後、モーターの角度はθm1、θm2、θm3とします。
とりあえず逆運動学で手先位置から関節角度、さらにそこからモーターの角度を求めたいのでまずはモーターの角度と関節角度の関係を求めます。
θ1=θm1、θ2=θm2は見たまんまなのですが、θ3が一見すると難しそうです。
と思わせておいて、M2とM3、J3とL3が重なっており、向かい合うリンクの長さが同じ場合は簡単です。
とりあえず、一部だけ抜き出して簡略化してみます。
このように常に向かい合うリンクが平行になるので、θ3はθm3からθm2を引いただけで導出できます。
つまりモーターの角度と関節角度の関係式は以下のようになります。
次に手先位置を関節角度から順運動学で導出します。
計算過程は省きますが以下のようになります。
そしてここから偏微分して手先速度と関節角速度の関係を求め、ヤコビ行列を導出します。
以下のように導出できます。
後は逆ヤコビ行列を導出して手先速度を入力すれば関節角速度が求まります。
次に手先の軌道を考えます。
とりあえず、初期位置と目標位置との距離ST、到達時間T、時間tから以下の式のように三角関数で導出します。
ちなみにこの計算式では以下のような軌道になります 。
急に加減速したら恐いので滑らかな軌道を描くようにしましょう。
この式から先端の目標加速度、速度、位置は以下の式で導出できます。
そして位置誤差のフィードバックを加えて先端指令速度を導出して、そこから関節角速度、関節角度を導出できます。
おそらく角加速度をセンシングする手段はないのでdθhで導出した関節角速度の指令値をそのまま積分します。
これで分解速度制御を行うために必要な数式は一通り導出できたので、ODEでシミュレーションを行います。ChoreonoidとかV-REPとか使わないのかよとか言われそうですが、あまりそういう気分でもないのでやめておきます。そりゃできればあの機構でシミュレーションをやりたいのですが、難しいので簡略化したモデルでシミュレーションしています。
動画は作っていないので、見たい人はここからシミュレーションのソースコードと実行ファイルをダウンロードしてください。
目標位置に手先が滑らかに移動できています。
と言うか、僕は何で持ってもいないロボットの制御則を考えているのでしょうね？
何だか悲しくなってきました。
次はここからどのようにRTCを設計するかを考えてみます。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
