個人的な雑記やら感想やらなんやかんや

ロボット、千葉ロッテマリーンズについていいかげんなことを書きます。

[32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42]

[PR]

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。

2024/11/23 (Sat)

ここを読んでもらえば分かると思うのですが、EdisonはPWMを256段階しか出せないらしいです。
つまりはPWMの周期20msの1～2msで180度回転するとして、約14度刻みでしか回転できないと言う事になりますかね？
ちなみに前々回撮った動画はPWMの周期を10msにして無理やり滑らかにしています。ラジコン用サーボはよく知らないのですけど、大丈夫なのですかね？

さすがにまずいと言うか、それでも7度刻みなのでこれにI2Cで通信する事にします。この製品ってEdison kit for Arduinoにも取り付けられるのだろうか？

と言いたいところですが、僕はこの製品を持っていないのでとりあえず手元にあるarduinoで代用します。arduinoをI2Cのスレーブにしてデータを受信するとサーボモータを制御するようにプログラムを作りました。皆さんが同じようなロボットを制御するときは上記の製品に置き換えてください。今の状態だとarduinoだけ使えとか言われそうですね。

正直なところ前との違いが分からないのですが、動きが滑らかになったような気がしなくもないです。
とりあえずEdisonに実装したRTCのソースコード、Arduinoに書き込んだソースコードはここに置いておきます。

Edisonのチップの表面には「What Will You Make?」と書いてある訳ですが、こっちが教えてほしいです。何を作ってほしいのですか？

何だか書くこともないので今日はこの辺にしておきます。

にほんブログ村のロボットのカテゴリから
全然人が来ない・・・

2015/03/10 (Tue) RTミドルウェア Comment(0)

EdisonでOpenRTM-aist(感想編)

凄く今更なのですが、Edisonでロボットアームを制御する事に関しては既に別の人がやっています。

どこかで違いを付けないとただの真似になるので何かしなくてはなりません
と言うよりも知らなかっただけですが。
あとこのページの人もアームを動かしているようです。

二番煎じは相当まずいです。正直なところここまでやったことだけでもそれなりに自信があったのですが、全く何の反応もないあたりからまずさが分かると思います。

実はニコニコ動画にも動画を上げていたのですが、僕とは全く関係ないコメントしか付いてません。

言い訳ですけど、ロボットを制御するとして安価に手に入るのは車輪で移動するロボットかアームに限られると思うので被るのは仕方ないと思います。多脚ロボットは高いですからね。

まあ自分の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を改良
実験

普通は7が最初に来るはずなのですが、最初はEdisonで遊びたかっただけなので仕方ないです。
今回は簡単な事しかしていませんが、ロボットを動かす上でシミュレーションは非常に重要です。
そしてシミュレーションで使った制御のプログラムをファイル、ライブラリ、RTCにしてもそのまま使い回せればバグが発生してロボット実機を壊す事もないと言う事です。
まあ今回のロボットはそんなに力が出せないので壊れる事は少ないとは思いますけど。

ただ、どうにもRTCの設計だけは疑問が残っています。
単一のRTCにして良かったのか、2つに分けた方が良かったのか正直分かりません。
詳しい人は教えてください。

にほんブログ村のロボットのカテゴリから
全然人が来ない・・・

2015/03/08 (Sun) RTミドルウェア Comment(0)

EdisonでOpenRTM-aist(実験編)

いよいよ実験します。

いい感じで動作できているようです。

とは言っても動いただけなのでここからどうするかが問題です。
何か変な動きでも良いので特殊な事をしなければ意味がありません。

今日は疲れたのでこれぐらいにしておきます。
アイデアが浮かんだらまた書きます。

にほんブログ村のロボットのカテゴリから
全然人が来ない・・・

2015/03/07 (Sat) RTミドルウェア Comment(0)

EdisonでOpenRTM-aist(準備編)

痛恨のミスをしていた事に気付きました。
手先のモーターがハンドを閉じるためのものだと思っていたのですが、手先を回転させるモーターでした。ひょっとしたら今までで一番アホなミスかもしれないです。

とりあえず今まで作成したシミュレータ、RTCは修正しておきました。

それからGUIを改良しました。

一見して何も変わっていないように見えますが、実はロボットのモデルを変更してあります。

それから例のロボットアームを買ってしまいました。
欲求に負けてしまいました。
何だか仕様書がないのですが大丈夫でしょうか？もちろん僕がロボットを壊すかもしれないと言う意味でですけど。
とりあえずサーボモータの動作確認をしただけです。
後シミュレータ、GUIのモデルの寸法を実機に合わせておきました。仕様書が無いために自分で測った長さなのでかなり適当です。

ここまででやった事は、

EdisonでOpenRTM-aist、OpenRTM-aist-Pythonの動作確認
Edisonでネームサービス、RTCの自動起動を実装
アームの手先位置制御に必要な数式の導出
アームのシミュレーション
アーム操作用GUIの作成

後はEdisonにアーム制御のRTCを実装するだけです。

全然関係ないけど、例のアームの動画を探していたら関連動画で面白い動画を見つけました。
ちょっと手際が良すぎるだろと思いました。

にほんブログ村のロボットのカテゴリから
全然人が来ない・・・

2015/03/06 (Fri) RTミドルウェア Comment(0)

EdisonでOpenRTM-aist(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つ言っておく事があります。
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を作ってみました。