[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
と思ったのですが、ロボットアームを持っていません。
動いている動画を見つけたので、どういう動作なのか見てみます。
一見、こんな感じのシリアルリンク機構ですが、
実際はこんな感じです。
本当は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を設計するかを考えてみます。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
ちなみにインストールの設定はどこに記述してあるかと言うと、src/CMakeLists.txtのinstall(TARGETS～の部分みたいです。
RTCを1つ1つインストールするのは面倒だし、RTC群で配布しているならまとめてインストール出来れば楽だと思いますけどね。
それはさておき一応EdisonでRTCの自動起動が形だけはできた訳ですが、何だか使いづらいです。
Edisonで制御するロボットを開発したとして、内部で複数のRTCが動いていたとしても一部のRTCを使いたいなんて事はそんなにないと思うので、もっと簡単に全てのRTCを管理する方法はないかと思ってこのRTCを作ってみました。
このRTCをアクティブ化、非アクティブ化するとlocalhostのネームサーバーに登録されたRTC全てをアクティブ化、非アクティブ化します。またExitすると他のRTCを全て終了させてPCをシャットダウンします。
いやでも妥協した結果なので微妙ですね。実行コンテキストを共有しない、状態は共有する複合コンポーネントがあればベストだったのですが、ないようなのでこういう形にしました。
これで準備は整ったので、あとはEdisonを使って何を作るかですね。
このロボットアームを使えば面白そうな感じはしますが、これを制御するRTC群とか作っても実用性は余りなさそうなので微妙ですね。RTM学習用と言ったところでしょうか？それはやらないと言ったと思うので、手を出しにくいです。
どうやら付属しているのはアームの部品とサーボモーター×4だけみたいなので、それは好都合ではあるのですが。
既存のRTM入門キットのようなものを調べてみると、以下のようなものがあります。
ビュートローバーRTC(￥102600)※生産終了
ビュートローバーRTC-BT(￥20520)
Kobuki(￥73440) ＋ PiRT-Unit(￥6300)
G-ROBOTS GR-001(￥151200)
他にも過去のRTMコンテストで発表された作品(￥3988)もあるみたいです。
こうして見ると移動ロボットばかりだなあ。
僕もできれば多脚ロボットをやってみたいのですが、さすがに1万円とか2万円とかじゃ済まないと思うので、アームで我慢します。
比較対象としては搭載したRaspberry Pi上でOpenRTM-aistが動作させたKobukiなのでしょうけど、先ほどのロボットアーム(￥16500)＋Intel Edison Kit for Arduino(￥11800)なのでKobukiに比べたら手を出しやすい値段ではあると思います。しかもロボットアームは元々Arduinoで制御するような仕様みたいなので特に改造する必要もないとは思います。
いやでもRTMの学習キットを作るというのが目的になるのは正直好ましくないなあ。
やはり笑いがとれるような機能が欲しいです。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
EdisonでもVNC接続してX Windowを起動すればGUIで操作できるとからしいですが、正直あまり食指が動きません。何でだろうな？
でもよく考えてみたらRaspberry Piに比べるとビデオ出力が無かったり、USBが1つしかなくてキーボードやマウスを取り付けられないとか別にデメリットでも何でもないわけだし、Edisonの方が流行りそうな感じですけどね。ちょっと高いか。
最初から無線LANに接続できるのは地味にメリットが大きいと思います。Raspberry Piだって無線LANドングルを使えば接続できるわけですが、何だか色々面倒です。まず、どの無線LANドングルにRaspbianが対応しているのかがよく分かりません。対応しているのを見つけたと思ったら「発熱が酷いから使わない方がいいよ」とか書かれているので、結局どれを使えばいいんだよという感じになります。
まあ、そもそも比較対象が少し違うか。
Edisonを使ってRTシステムを組む場合、どういう構成にすべきか？
まず、アクチュエータにしてもセンサにしてもGPIOで制御するか、SPI、I2C等で何らかのデバイスに通信するかと言う事になると思いますが、接続したアクチュエータ、センサを個別にRTコンポーネント化すべきか？と言われれば正直迷う所ですね。基本的にRTシステムエディタでの操作は母艦PCで行うと思うのですが、組込み機器の場合単一のRTCの方が分かりやすいように思います。もちろん粒度の問題もありますが。例えば12自由度の4脚ロボットを開発するとして、12個のモーター制御RTCを起動する人なんてほとんどいないと思いますので。
完全に個人的な考えですが、以下の手順でRTCの起動、終了が出来ると簡単に使えると思います。
- Edisonの電源を入れるとネームサーバー、RTCが起動
- RTシステムエディタでRTCをExitすると自動的にシャットダウンする
Edisonの電源を入れるだけで、後は全てRTシステムエディタ、rtshell、もしくは他のRTCで操作したいと思っています。とにかくリモートログインをしたくないのです。
まあrtcdとか使えば複数のRTCを起動した状態でも可能ですけど、全てのRTCを終了させないとシャットダウンしないのでなんだかややこしい事になりそうな感じはします。
いやでもカメラとかURGとか使おうと思ったら既存のRTCを使った方が開発が楽だろうし、複合コンポーネントにでもしておけばいいのかな？
Edison起動
ネームサーバー起動
rtcdで必要なRTCを起動
rtshellでデータポート接続
rtshellで複合コンポーネント化
複合コンポーネントをExit
シャットダウン
こんな感じの手順でやれば使いやすいように思います。
rtc.confで設定しておけばRTCがなくなった場合にマネージャ、プロセスを自動的に終了させることはできるので、rtcd終了直前にos.system("shutdown -h now")とか書いておけばシャットダウンしますかね？
C++版とPython版のrtcdを両方起動している場合はどうしましょう。
マネージャ終了時にネームサーバーにRTCが残っていないかの確認をさせておきますか。
今の所、複合コンポーネント化以外の実装できまています。
複合コンポーネントはPeriodicStateSharedCompositeというタイプに設定する必要があると思うのですが、やり方がよくわかりません。というよりRTシステムエディタでPeriodicStateSharedCompositeに設定してもエラーが出て複合コンポーネントを作成できません。PeriodicECSharedComposite、GroupingではExitしても複合コンポーネントが消えるだけなので意味はないでしょうし、PeriodicStateSharedCompositeに設定する必要がありそうです。
複合コンポーネントのタイプについて、僕の認識が合っているかどうかは知りませんがおそらくこんな感じだと思います。
Grouping：RTシステムエディタ上で見た目だけ複合化する
PeriodicECSharedComposite：実行コンテキストを共有する
PeriodicStateSharedComposite：実行コンテキスト、状態を共有する
いやでも実行コンテキストを共有されるのは少し困るな。
状態だけ共有して、実行コンテキストは共有しないみたいな事は出来ないのでしょうかね？
Groupingはこんな感じです。
そもそもRTCと実行コンテキストとの関係と言うのが非常に分かりづらいのですが、普通にRTCを起動するとRTCと実行コンテキストは1対1です。
ただ他のRTCに関連付けられた実行コンテキストにアタッチしたり、あるいは以前の記事で作ったプログラムみたいにRTCを起動した時点で複数の実行コンテキストに関連付けられていると言った事もできます。
この場合、RTCは実行コンテキストごとに状態をもっているので、EC1ではActive、EC2ではInactiveな状態もあると言う事です。
つまりPeriodicECSharedCompositeでは新たに実行コンテキストを作成して、その実行コンテキスト内で各RTCのロジックを実行すると言う事になります。
つまり、図にするとこんな感じです。
- 複合コンポーネントをRTシステムエディタで操作すると全てのRTCがアクティブ化、終了等を行う
- RTCを個別に操作した場合、他のRTCの状態は変化しない
- 実行コンテキストは共有しない
と言うのが理想なのですが、当てはまるタイプが無かったみたいです。
PeriodicStateSharedCompositeでいけると思ったのですが、実行コンテキストの共有はやらなくていいです。
上記の複合コンポーネントを実現しようとした時に、複合コンポーネントをアクティブにしたときに各RTCはどの実行コンテキストについてアクティブにすべきか？と言われればowned0で構わないと思いますけどね。Edison上で動作するRTCを他の実行コンテキストにアタッチするなんて、正直意図がわからないのですが。同期させたいのなら複合コンポーネント内部でさらにPeriodicECSharedCompositeの複合コンポーネントを使えば良いので、別に問題はないと思います。
いっその事操作用RTCを起動しておいて、そのRTCがExitされたらシャットダウンするとかの方が良いかもしれないです。いやでもまとめてアクティブ化できないと不便だし、操作用RTCのonActiveでネームサーバー内のRTCを全てアクティブにするとか、そう言う事をすれば実現は一応可能ですが、なんだかもっとやり方はないのかと思います。
余計な事を言いすぎましたが、今の所こんな感じに実装できています。
やはり少し面倒です。
と言うか、RTシステムエディタのネームサーバの追加も自動的にやってほしいです。
例えばこんな感じでRTCの自動起動を実装したEdisonを積んだロボットを入手したとして、すぐに使えるかと言えば微妙ですね。
無線LANの設定が必要かと思ったのですが、J16に接続すればUSB経由の通信でRTC同士の通信も普通にできるので別に必須ではないです。
と言うかraspberry piでのRTCの起動スクリプトは既に存在するみたいだけど、電源切る時はどうしているのでしょうね？
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
よく考えてみたら途中で環境を変えた事もあって、インストールの手順をまとめていませんでした。先に言っておきますが、以下で説明するのはubilinuxでの手順です。Yocto linuxでもインストールはできるので、そちらを知りたい方は過去の記事を参考にしてください。
まずはC++版のインストールの手順です。
1 apt-getでcmake、uuid-dev、libomniorb4-dev、omniidlをインストール
apt-get install cmake uuid-dev libomniorb4-dev omniidl
2 OpenRTM-aistをソースからビルド
ここからOpenRTM-aist-1.1.0-RELEASE.tar.gzを入手して解凍
ソースからビルドしてインストール
解凍したフォルダに移動して、
と入力
おそらくこんな感じです。
sudoは最初からインストールされていないので、まだインストールしていない場合はapt-getでインストールしておいてください。
Doxygenは別にドキュメントを生成する事もないでしょうし、インストールしなくて良いと思います。
Python版の手順は以下の通りです。
1 apt-getでpython-dev、libomniorb4-dev omniidlをインストール
apt-get install python-dev libomniorb4-dev omniidl
2 omniORBpyをソースからビルド
ここからomniORBpy-3.7.tar.bz2を入手して解凍
解凍したフォルダに移動して、
と入力
bzip2をインストールしていないと解凍に失敗するのでインストールしていない場合はapt-getでインストールしておいてください。
ここからOpenRTM-aist-Python-1.1.0-RC1.tar.gzを入手して解凍
解凍したフォルダに移動して、
python setup.py build
sudo python setup.py install
と入力
これで多分合っていると思います。
Java版は・・・・別にEdisonでJava使うメリットもないだろうし、インストールする必要はなさそうですね。
今回は珍しく役に立ちそうな記事を書けたと思います。
追記
どうにもomniORBをソースからビルドしてインストールしないとomniORBpyのビルドに失敗してしまいます。You must specify the omniORB root directory.とか怒られるのですが、そもそも指定する方法が分かりません。詳しい人は教えてください。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
まあ詳しい事は他のサイトに載っていると思うので、一部だけですけど。
まず、生成したRTCのテンプレートのフォルダの直下にあるCMakeLists.txtの、
find_package(OpenRTM REQUIRED)
はどこからOpenRTM-aistのパッケージを見つけているかと言うと、
- 環境変数PATHからC:\Program Files\OpenRTM-aist\1.1\binを見つける
- binディレクトリなのでC:\Program Files\OpenRTM-aist\1.1に変換
- C:\Program Files\OpenRTM-aist\1.1にcmakeディレクトリがあるので、そこからOpenRTMConfig.cmakeを検索
PATHからC:\Program Files\OpenRTM-aist\1.1\binを消したらCMakeに失敗したのでおそらく合っていると思います。
まあ他の人のPCで環境変数がどうなっているかなんて知らないので、違う所から検索される事もあると思います。
次にOpenCVを使うときは、
find_package(OpenCV REQUIRED)
と記述すると思いますが、環境変数にパッケージ名_DIRがあればそこから検索する事ができるので、OpenCV_DIRから検索していると思います。
ただ、binフォルダにパスを通していたりすると優先順位がどうなるのかは分かりません。
最後にQtを使う場合を考えてみたいと思います。
方法としては、
- C:\Qt\Qt5.3.2\5.3\msvc2010_opengl\binにパスを通す
- Qt5Widgets_DIR等の環境変数を設定する
- CMAKE_PREFIX_PATH等の環境変数にC:\Qt\Qt5.3.2\5.3\msvc2010_opengl\lib\cmakeを追加する
Qt4なら2でも良いかもしれないですけど。
シグナル、スロットを使う場合はmocファイルを生成する必要があります。
どうやら、set(CMAKE_AUTOMOC ON)と記述しておけば勝手にやってくれるみたいです。
Qtに関してはqmakeを使うよりもCMakeを使ってプロジェクトを作成した方が簡単かもしれないですね。
では自分でFind～.cmakeや～Config.cmakeを作成するにはどうすれば良いのか？
それは僕が教えてほしいです。いやだって意外に情報少なくないですか？
Linuxユーザー特有の「知りたい事は自分で調べろ」という風潮は嫌いです。
CMakeもなあ、せめてVC++やCodeBlocksのプロジェクトから逆にCMakeLists.txtが生成出来れば楽なんですけどね。ひょっとして出来るのでしょうかね？
そもそもCMakeに対応しているライブラリなんて一部だろうし、やっぱり何だか使いづらい。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
