四足歩行ロボット制御用RTコンポーネント群
四足歩行ロボット制御用RTコンポーネント群
投稿日時:
水, 2016-10-26 09:18
概要・特徴
- 四足歩行ロボットを制御するためのRTC群
- クロール歩容、間歇クロール歩容、トロット歩容による歩行
- 再利用性向上のために多足歩行ロボット共通インタフェースの提案も行う
- 以下のハードウェアに対応
- SunFounder製四足歩行ロボット(Crawling Quadruped Robot Kit for Arduino)
- LEGO Mindstroms EV3により組み立てた四足歩行ロボット
仕様
- 言語: C++
- OS: WIndows、ev3dev
- RTミドルウェア:OpenRTM-aist-1.1.2-RELEASE(Windows)、OpenRTM-aist-1.1.1-RELEASE(ev3dev)
- シミュレーター:Open Dynamics Engine 0.13
ソースコードおよびマニュアル
- マニュアル
- ソースコード
概要スライド
ライセンス
- GPL
動画
問合先(メールアドレス):
n-miyamoto[at]aist.go.jp
最終更新日時:
金, 2016-12-02 14:22
コメント
内容を確認させていただきました.マニュアル,RTC等非常に整備されており非常に見応えがありました.
指摘では無いのですが,設計思想について,3点質問があります.
・Foot_Position_Controller に固定数の足関節分のデータポートが必要なのは汎用性,拡張性が少し気になりましたが,一般的に十分な関節数なのでしょうか
・もしも今後,2足,6足,8足歩行に対応する場合,どの部分が再利用できるのでしょうか
・有り得ない関節角度などが入力された場合などの異常値チェックがコード中は見つけられなかったのですが,本来はどのコンポーネントでチェックすべきでしょうか
産総研の宮本です。 コメントしていただいてありがとうございます。
まずFoot_Position_Controllerのmotor_pos_0からm_motor_pos_3のデータポートは、EV3を4台使用したロボットと通信するために後付けしたものなので、あまり拡張性は考えていません。 このRTCは動画に示すような対称な4足歩行ロボットの脚配置にしか対応しておらず、6脚等に対応させようとするとコンフィギュレーションパラメータが多くなり使いづらくなりそうです。条件を限定しているのであの程度の数で済んでいるのだと思います。設定ファイルを別に読み込ませるなどで対応は可能かもしれませんが、まだ対応できていません。
一般的に十分な脚関節数かについてですが、静的に安定な歩行をするために最低限必要な脚の数が4脚です。ただ6脚にすることでより安定な歩行は可能なので、4脚で十分かどうかは何が目的かによって違うと思います。
2足、6足、8足に対応する場合に、どの部分が再利用できるかについてですが、Crawl_Gait_Controller、Intermittent_Crawl_Gait_Controllerは四足歩行ロボット制御のためのRTCであり、Foot_Position_Controllerも四足歩行ロボットにしか対応していないため、サーボ制御部分のRTCしか現在は再利用できません。 少なくともクロール歩容、間歇クロール歩容でそのまま6足歩行ロボットを歩かせるのは無理なので、この部分の再利用は不可能だと思います。
ただ、例えば6足歩行ロボットにCrawl_Gait_Controllerを適用して4足で歩行し、残りの2足で作業を行う等はできると思います。
あり得ない関節角度が入力された場合ですが、異常値チェックはFoot_Position_Controllerで行い、さらにサーボ制御RTCでも行った方が安全だと思います。 シミュレーションを実行した際に関節角度が可動範囲を超えてシミュレーター上のロボットが爆発四散することがあったので気にはなっていたのですが、対策を忘れていました。指摘していただいてありがとうございます。
ご回答いただきありがとうございました.
設計思想について理解できました.
また,追加のコメントなのですが,
静的解析ツールでチェックしたところ,コードのクリーニングができそうな箇所が何件か見つかりましたので,修正する際は下記を参考にして下さい.
https://github.com/takahasi/RTM_Contest_2016/blob/master/scripts/report_20161121.txt
教えていただいてありがとうございます。
関数の未使用以外の警告については修正を行ったので改善したとは思います。
見応えがあるプロジェクトですね.素晴らしいと思います.ギリギリになってしまったのでコメントだけです.
共通インターフェースというのを提案しているのが挑戦的で素晴らしいと思っています.議論がしたいです. 脚がラジコンサーボで,ロボットが軽量だから問題にはなりにくいのですが,ロボット本体から情報を収集する側のインターフェースについて定義を進めてもらえれば,汎用性の高いインターフェースが出来上がると思います.特にロボットの重量が大きかったり,不整地であれば,目標値と脚の関節の現在地が変わるものと思います.
軌道や安定余裕も含めた一つのデータ型にまとめたり,脚はアームとの対称性も感じるので,そちらにならってサービスポートで運動学を提供するのも一つの手かな,と思いました.
コメントしていただいてありがとうございます。
ロボット本体から情報を収集する側のインターフェースについてですが、まだよく考えていない状態です。 駆動サーボ制御コンポーネントの入力がTimedDoubleSeq型なので、同じTimedDoubleSeq型で出力して、それで関節の現在値を取得すればいいという安易な考えをしていたのですが、関節角度を脚先位置への変換をどこでやるかが問題になりそうです。 多足歩行ロボットのRTC設計はいままであまり考えられていなかった事だと思うので、今回提案をしたことによって今後議論が活発になればいいとは思います。
軌道や安定余裕を含めた一つのデータ型にまとめるということについてですが、安定余裕にもいくつか種類があるので例えば縦安定余裕だけ、NE安定余裕だけということをしてしまっていいのかと考えたのでデータ型には含めませんでした。
確かにアームの共通インターフェースのようにサービスポートを使つのも一つの手段だとは思うのですが、アームの場合は「目標位置に直線補間で移動しろ」といった操作を行うと思うのですが、多足歩行ロボットの場合は連続的に指令を与える必要があるのでサービスポートが妥当なのかという疑問はあります。
返信ありがとうございます.ここで話をするのが良いのかわかりませんが,もう少しだけコメントを.
TimedDoubleSeqのようなデータ型は,一般的すぎるので使わない方がいいと思っています. 関節角度についてはActuatorやJointPosのようなデータ型を使った方がいいと考えています.関節軌道のJointTrajectoryのようなクラスも必要かと思っています.Trajectoryを一気に送信する感じに加えて,不測の事態にキャンセルして次のTrajectoryを送るようにするともう少し実用的になると思っているのですが・・・
また,ロボットに関する情報(タイプや脚数,各脚の根元のジオメトリ情報,DHパラメータ)などをサービスで取得できると,コントローラ側が対応するハードウェアか否かを判定できると思います. まあ,この辺はコントローラのコンフィグレーションとするのもありでしょうけど. これのついでに脚の関節角度や足先の位置・状態を取得するインターフェースがあれば良いかと思います.逐次制御用のデータポートを持つというのももちろんありで,アームの方のCommonとMiddleのような位置付けになればいいのではないでしょうか.
同様に安定余裕については,StabilityMargin型のようなデータ型ないしはTypedefを作るのが良いと考えています.どうせLeg型を使うにはIDLコンパイルが必要ですから,この際,使いやすいデータ型は捨てて,何を意味しているのかをデータ型でわかるようにしてあげればマニュアルいらずになると考えています. 正規化エネルギー安定余裕もスカラ量なので,どちらもDoubleのTypedefで済むとは思いますが,この分野は専門じゃないので,ベクトルの安定余裕なんてあるんですかね?X-Y方向によって安定余裕を変えるというのはありそうですが・・・ あとは安定余裕をEnumで定義しておいて,typeなどのメンバとすれば,どのタイプの安定余裕かがコンシューマに伝わります.
コメントありがとうございます。
関節角度にActuatorやJointPos等のデータ型を使う件ですが、それはその通りだと思います。
ただ、Actuator型のデータポートを使用したRTCを一度も見たことがないのですが、どこかにあるのでしょうか?
データ型の存在自体が知られていない→RTCが開発されない→データ型の存在が知られないという負の連鎖になっているのではないかと少し不安です。
関節軌道の件ですが、歩行ロボットというよりも多関節ロボット全般の話だと思うので、確かにここで話をするのはあまりよくないかもしれないです。
ロボットに関する情報をサービスで取得する件ですが、おっしゃる通り必要だと思うので今後考えていきたいと思います。
コメントで教えていただいた以外にも、脚の可動範囲を取得することが重要ではないかと考えています。 例えば、以下の論文ではTITAN Ⅷという四足歩行ロボットの可動範囲を扇形と定義してあるので、アーム共通インターフェースのようにx軸、y軸、z軸の制限だけでは不十分かもしれません。
http://ci.nii.ac.jp/naid/10002865792
安定余裕の件ですが、それだと1種類の安定余裕のみやり取りするという事になると思うのですが、それでいいのかどうかがよく分かっていない状態なので、少し考えてみます。
ベクトルの安定余裕は分からないです。すみません。
あと,上記のコメントとは関係なく,
LeggedRobotの部分のコードが共通部分だと思いますが,gitの場合はsubmoduleを使えばgitリポジトリから別リポジトリを参照できるので,一つにまとめることができます.ご存知でしたらすみません.
コメントありがとうございます。
gitのsubmoduleは個人的に嫌いなのであまり使っていません。 普通にクローンしてもサブモジュールの中身をクローンしてくれないところと、submoduleのリポジトリを更新してもsubmoduleは更新されないので、なんだか癖が強くて使いづらいような気がしています。