Closed MoriKen254 closed 6 years ago
動作確認が遅くなってすみません。
当方の indigo 環境で fix-travis-indigo ブランチを試したところ、 下記のエラーにより catkin_make が通りませんでした。
-- +++ processing catkin package: 'motoman_point_cloud'
-- ==> add_subdirectory(motoman_project/motoman_recognition/motoman_point_cloud)
-- Using these message generators: gencpp;geneus;genlisp;genpy
CMake Warning at /opt/ros/indigo/share/catkin/cmake/catkinConfig.cmake:76 (find_package):
Could not find a package configuration file provided by "motoman_moveit"
with any of the following names:
motoman_moveitConfig.cmake
motoman_moveit-config.cmake
Add the installation prefix of "motoman_moveit" to CMAKE_PREFIX_PATH or set
"motoman_moveit_DIR" to a directory containing one of the above files. If
"motoman_moveit" provides a separate development package or SDK, be sure it
has been installed.
Call Stack (most recent call first):
motoman_project/motoman_recognition/motoman_point_cloud/CMakeLists.txt:4 (find_package)
-- Could not find the required component 'motoman_moveit'. The following CMake error indicates that you either need to install the package with the same name or change your environment so that it can be found.
CMake Error at /opt/ros/indigo/share/catkin/cmake/catkinConfig.cmake:83 (find_package):
Could not find a package configuration file provided by "motoman_moveit"
with any of the following names:
motoman_moveitConfig.cmake
motoman_moveit-config.cmake
Add the installation prefix of "motoman_moveit" to CMAKE_PREFIX_PATH or set
"motoman_moveit_DIR" to a directory containing one of the above files. If
"motoman_moveit" provides a separate development package or SDK, be sure it
has been installed.
Call Stack (most recent call first):
motoman_project/motoman_recognition/motoman_point_cloud/CMakeLists.txt:4 (find_package)
-- Configuring incomplete, errors occurred!
See also "/home/nishio/Workspace/motoman_travis_ws/build/CMakeFiles/CMakeOutput.log".
See also "/home/nishio/Workspace/motoman_travis_ws/build/CMakeFiles/CMakeError.log".
make: *** [cmake_check_build_system] Error 1
Invoking "make cmake_check_build_system" failed
indigo-devel ブランチで catkin_make が通ることを確かめた後、 再び fix-travis-indigo ブランチで catkin_make を行うと下記のエラーで止まりました。
-- +++ processing catkin package: 'motoman_demo'
-- ==> add_subdirectory(motoman_project/motoman_demo)
CMake Error at /home/nishio/Workspace/motoman_travis_ws/devel/share/ar_pose/cmake/ar_poseConfig.cmake:141 (message):
Project 'motoman_demo' tried to find library 'ar_pose'. The library is
neither a target nor built/installed properly. Did you compile project
'ar_pose'? Did you find_package() it before the subdirectory containing its
code is included?
Call Stack (most recent call first):
/opt/ros/indigo/share/catkin/cmake/catkinConfig.cmake:76 (find_package)
motoman_project/motoman_demo/CMakeLists.txt:3 (find_package)
-- Configuring incomplete, errors occurred!
See also "/home/nishio/Workspace/motoman_travis_ws/build/CMakeFiles/CMakeOutput.log".
See also "/home/nishio/Workspace/motoman_travis_ws/build/CMakeFiles/CMakeError.log".
make: *** [cmake_check_build_system] Error 1
Invoking "make cmake_check_build_system" failed
Travis が通っているということは私の環境に間違いがあるのでしょうか..? お力になれず申し訳ありません。。
レスありがとうございます!^^ 私もここでの議論を通して、皆さんとともに勉強させてもらえれば幸いです。
とりあえず、前者のmotoman_moveit
が見つからないのは、CMakeLists.txt
でfind_package
してるのに、package.xml
で
indigo-devel
でとりあえずその辺をうやむやにしてmotoman_moveit
がビルドできたから、たまたま解決されたという格好です。問題はありますね汗。
次に、後者についてはar_pose
が無いからcatkin
が怒り心頭な訳ですね。ミソは下記のpackage.xml
だと思います。
https://github.com/Nishida-Lab/motoman_project/blob/fix-travis-indigo/motoman_demo/package.xml
indigo-devel
ではar_pose
の依存関係を記述していないのですが、fix-travis-indigo
ではこれを書いています。なぜなら、Travis
だと、launch
ファイルからar_pose
を呼んでいるのに、なんでpackage.xml
側でその依存関係を書いていないんだよ?あんたは使えるからいいかもしれないけど、他の人が使うときに実行時エラーになるだろ?ちゃんと面倒見ろよ!ということでError
にさせられてしまうっぽいです。(こんな説明でいいのか笑)
というわけで、以下のコマンドを実行して依存関係を解決した上でにcatkin_make
したらどうなりますかね?Travisだと、これと同等のことをしてからビルドをしているので。
$ cd <catkin_ws>
# aptで取得できない依存パッケージを引っ張ってくる
$ wstool init src src/motoman_project/dependencies.rosinstall
$ wstool update -t src
# aptで取得できる依存パッケージを引っ張ってくる
$ rosdep update
$ rosdep install -i -r -y --from-paths src --ignore-src
# libfreenect2をインストールする
$ cd src/libs/libfreenect2
$ cmake .
$ make
$ make install
# catkin でビルド
$ cd <catkin_ws>
$ catkin_make
# test
$ catkin_make run_tests
$ catkin_test_results
よろしくお願いいたいます。
ご返信ありがとうございます。
ご教示いただいたコマンドをすべて実行しても、
catkin_make
で ar_pose
のエラーが出ます..
ar_pose
はちゃんと入っている様子なんですが、、
-- +++ processing catkin package: 'motoman_demo'
-- ==> add_subdirectory(motoman_project/motoman_demo)
CMake Error at /home/nishio/Workspace/motoman_travis_ws/devel/share/ar_pose/cmake/ar_poseConfig.cmake:141 (message):
Project 'motoman_demo' tried to find library 'ar_pose'. The library is
neither a target nor built/installed properly. Did you compile project
'ar_pose'? Did you find_package() it before the subdirectory containing its
code is included?
Call Stack (most recent call first):
/opt/ros/indigo/share/catkin/cmake/catkinConfig.cmake:76 (find_package)
motoman_project/motoman_demo/CMakeLists.txt:3 (find_package)
-- Configuring incomplete, errors occurred!
See also "/home/nishio/Workspace/motoman_travis_ws/build/CMakeFiles/CMakeOutput.log".
See also "/home/nishio/Workspace/motoman_travis_ws/build/CMakeFiles/CMakeError.log".
make: *** [cmake_check_build_system] Error 1
Invoking "make cmake_check_build_system" failed
試しに、
motoman_project/motoman_demo/CMakeLists.txt
のfind_packageからar_poseを除外した上でcatkin_makeしてみてもらえますか?
motoman_demo の CMakeLists.txt から ar_pose を除外すると catkin_make は通りました..
ご指摘いただいた2件の不要な依存関係を除外し、Travisが通ることを確認しました。
どうでしょう。
今回のご変更で、catkin_make が通るようになりました! 2つのPCで確認できたので、大丈夫かと思われます。
ありがとう!助かります!(不備がまだまだ多く、ごめんなさい汗)
あとは、実機もindigoのままかな?それなら、念の為実機で簡単に確認してみてもらって、問題がなければマージをお願いします。
実機での確認が大変遅くなり申し訳ありません。 実機はindigoのままです。
下記のコマンドを別々のターミナルで実行し、Rviz上のインタラクティブマーカーで指定した手先位置に実機を動かす試験を行いました。
$ roscore
$ roslaunch motoman_control sia5_with_dhand_and_multi_kinect_streaming.launch
$ roslaunch motoman_control sia5_real_control.launch
$ roslaunch motoman_moveit sia5_with_dhand_moveit_planning_execution.launch
これらのコマンドは現在実機で運用している demo/devel
ブランチで動作確認ができているものです。
fix-travis-indigo
ブランチで上記のコマンドを実行し、RvizとMoveit!が立ち上がっている状態でインタラクティブマーカーを動かして Plan → Execute を実行すると、Execute時に下記のエラーが発生しました。
[ INFO] [1534227275.021400200]: Received new trajectory execution service request...
[ INFO] [1534227275.021538893]: Returned 0 controllers in list
[ERROR] [1534227275.021584391]: Unable to identify any set of controllers that can actuate the specified joints: [ joint_b joint_e joint_l joint_r joint_s joint_t joint_u ]
[ERROR] [1534227275.021610278]: Known controllers and their joints:
このエラーの原因は sia5_with_dhand_moveit_planning_execution.launch
において controllers_config
に /sia5_with_dhand/fake_controllers.yaml
が指定されていることと思われたので、takaki/fix-travis-indigo
ブランチで変更 584042f を加えたところ、正常に動くようになりました。
変更点は、sia5_with_dhand_moveit_planning_execution.launch
における controllers_config
を moveit_planning_execution.launch
のdefaultから設定するようにした点です。
この対処法は最適ではないと思いますが、似たようなエラーが indigo-devel
ブランチでも発生するため、何らかの対策が必要かと思われます..
@TakakiNishio 確認ありがとうございます!やっぱり動かさないとですね。
さて、状況は理解しました。下記2つのファイルを比較し、現状の問題を解決する手段を見つけて、実機での動作を確認してみて下さい。
motoman_moveit/config/sia5/controllers.yaml
controller_list:
- name: sia5_controller
action_ns: follow_joint_trajectory
type: FollowJointTrajectory
default: true
joints:
- joint_s
- joint_l
- joint_e
- joint_u
- joint_r
- joint_b
- joint_t
motoman_moveit/config/sia5_with_dhand/fake_controllers.yaml
controller_list:
- name: fake_arm_controller
joints:
- joint_s
- joint_l
- joint_e
- joint_u
- joint_r
- joint_b
- joint_t
- name: fake_gripper_controller
joints:
- dhand_finger_base_left_joint
- dhand_finger_middle_left_joint
- dhand_finger_top_left_joint
- dhand_finger_middle_middle_joint
- dhand_finger_top_middle_joint
- dhand_finger_base_right_joint
- dhand_finger_middle_right_joint
- dhand_finger_top_right_joint
以下、私の所感。参考程度に。
fake
ではないほんちゃん用のcontrollers.yaml
に昇格させる。motoman_moveit/launch/sia5/sia5_with_dhand_moveit_planning_execution.launch
でコメントアウトした下記ラインを復活させ、fake
ではないyamlファイルを明示的に読み込む。<!-- <arg name="controllers_config" value="$(find motoman_moveit)/config/sia5_with_dhand/fake_controllers.yaml"/> -->
取り急ぎ。
ご返信ありがとうございます!
ご提案いただいたアドバイスを参考に、takaki/fix-travis-indigo
ブランチにおいて変更 072ad0e を加えました。
実機で問題なく動作することが確認できましたので、こちらもfix-travis-indigo
ブランチにマージしてよろしいでしょうか?
ありがとうございます!実機での動作確認も、いいですね。
https://github.com/Nishida-Lab/motoman_project/commit/072ad0e8aec2041442afbb2dcc40eaf9df0ffb87 を確認しました。
念の為確認ですが、以下のgripper側のコントローラの対応は不要でしょうか?launchファイルの名称を見る限り、dhandに対応していると思われるので。せめてfakeぐらい入れておく必要は?
もし不要であればこのままマージ、必要であれば対応してからマージとしましょう。一回ご自身で調べて判断してみてもらえますか?
8月中で様子を見て、やっぱり不要と言うことであれば、マージしてしまいましょう。
たとえば、gripper 側のコントローラをちゃんと設定しないと、MoveItと連携する上で何かできなくなってしまうことはないか?等
私は実装者ではないのではっきり回答できないのですが、実績的には問題ないのかなーと、思っています。
これを見ると、一応gripperのコントローラが定義されているようですね。arm用で言うところのFollowJointTrajectory
に対して、gripper用のaction としてGripperCommand
というものがあるらしいので、真面目にお作法に乗っかるならこれを使うのかな、というイメージです。
これはoptionalだと、こちらにも記載されているようですしね。
一応motomanの他のconfigをざっと見てみたのですが、jammingについてもGripperCommand
を使っている形跡がないので、現状問題は起きていないのかな、と推察しています。
運用上は、プランニングをMoveItにやらせて、pickingは独自のROS MessageでI/Fさせている、という感じ?
この辺りの実機の仕様は、OBの @Ry0 くんとか @RyodoTanaka くん辺りが反応してくれると @TakakiNishio くん助かるんじゃないかな、と思います。
- name: fake_gripper_controller
joints:
- dhand_finger_base_left_joint
- dhand_finger_middle_left_joint
- dhand_finger_top_left_joint
- dhand_finger_middle_middle_joint
- dhand_finger_top_middle_joint
- dhand_finger_base_right_joint
- dhand_finger_middle_right_joint
- dhand_finger_top_right_joint
これをfakeではないコントローラにしたものを登録する必要があるか?という議論です。dhand側のコントローラの情報は下記ファイルが参考になるのかなと思っています。
@MoriKen254 @TakakiNishio gripperのコントローラですが,設定していません.経緯と理由は以下のとおりです.
通常のピッキング(チャックで挟むようなピッキングを指す)を行うことができなかったため,コントローラを設計しませんでした.
D-Handは閉リンク機構を有しているためURDFに記述できず,仮にコントローラを設計したとしてもその開閉をうまく反映できないので,設定していません. また,仮に設定するのであれば,実際の開閉に使用されている位置決めサーボモータ(IAIのやつ)のjointを新たにURDFに記述し,そこにコントローラを設定する必要があります.
Moveit!のピッキングタスクにおいて,把持対象を把持したあと,手先リンクにひっつけたままのプランニングを行うことができない...かもしれない.(これは調査が必要) 詳しくは,NASに上がっているROS本(洋書)に通常の場合のセッティング方法とその例としてリポジトリの紹介があるのでそれを参考にすると良いかも.
Moveit!に一応用意されているのに使わないのは後々何かありそう..?
以上です.よろしくお願いします.
すみません. 間違って閉じてしまいました...orz
仮にD-Handのグリッパコントローラを設計するのであれば
上記の2つをaction messageを介して行ってくれるようなドライバを作成する必要があるかと思います.
modbusについては,Pythonライブラリの minimalmodbus
というのを使って制御してあります.
minimalmodbus
についてわからなければ, @thibaultbarbie がdhand_driver
を作ってくれた人なので,聞いてみると良いと思います(英語のリファレンスも用意してくれてたので,とりあえずもらって読んでみると良いと思います).
逆に,Pythonでしか実装していないので,C++で実装する必要が出てくると,modbus の C++ライブラリを探してくるところからやる必要があります.
modbus ってそもそも何?というのはググればわかりますが,大雑把に言うと FA機器に広く使われている通信規格みたいなもんです.
以上,補足でした. よろしくお願いします.
詳細なご解説、ありがとうございます!
閉リンクが絡んでいて、色々厄介なことがよくわかりました。
そして、現状のシステムにおいて、dhandが初期状態以外の開き具合だと、MoveIt側が現実の情報を把握できないために、例えば障害物回避ができない可能性がありそうですね。
それを解決するためには、アクチュエータの位置に合わせて他のJointの現在値を仮想的に計算してjoint_states
にパブリッシュする必要がある。(私がSteering Drive Controllerを作ったときにも似たような対応をしました汗。ROS2でこの辺もいい感じに直ってくれたら嬉しいのですが…。)
順運動学はそれで良さそうな気がします。この状態をjoint_states
にさえ送っておけば、グリッパとアーム先端間の逆運動学もMoveIt側に任せても大丈夫、なんだと思っています。
action を介してIAIドライバに司令を送るdriverノードが必要なことも、よく分かりました。 modobus周りは @thibaultbarbie くんに聞けば良さそうですね。メッセージのハンドリングだけなので、速度の問題さえなければ、Pythonで十分な気はします。
以上を統合したMoveIt対応ROS パッケージを完成させようとしたら、それなりのパワーが必要ですね。
これまでは、dhandの開閉状態を評価しなければならないほどシビアな判定を要するデモもなく、まずは動作させることを優先する必要があったという経緯もあったでしょう。詳細な仕様を意識しすぎてデモができないのでは、元も子もありませんからね。現状のパッケージ構成となっている理由が良く分かりました。
情報がクリアになりました。ありがとうございます。
まず本プルリクはマージし、当該案件はIssueとして残しておいて、必要となったとき or 趣味で対応するようにして良さそうですね(デイタイムにlab常駐してフルコミットできるなら、私でもいくらでも実装したいのですが…笑 😭 )。
質問ついでですが、demo/devel
とindigo-devel
の違いがあるみたいですけど、demo/devel
の内容もindigo-devel
に混ぜ込んじゃっていいんですかね。demo/stable
ってブランチも気になる笑。
というのも、最近ブランチが増えてしまったので、整理したいなと。本件も一旦本プルリクをマージした後、別Issueにしようと思います。
@MoriKen254
順運動学はそれで良さそうな気がします。この状態をjoint_statesにさえ送っておけば、グリッパとアーム先端間の逆運動学もMoveIt側に任せても大丈夫、なんだと思っています。
これは単純な質問なんですが,Gripper部分もMoveit!はIKを解いてくれるんですかね? Moveit! setup assistant で設定する際に,D-Handの手先まで Arm グループに入れてしまえばできるとは思うのですが,それはMoveit!の設計趣旨違うと思ってます. なので,仮にMoveit!対応のD-Handコントローラを仮に設計したとしても,D-Hand部分についてはIKは解いてくれないものと考えてました.
最近ブランチが増えてしまったので、整理したいなと
これについては, @Ry0 もSlackでちょいちょい気にしてました笑 僕も気にはなってたんですが,かと言って僕らが口を出して現役の方の混乱を生むのの良くないなと思ってたんで,研究室所属の方にお任せしたいと思ってます.
demo/devel
とindigo-devel
の違いがあるみたいですけど、demo/devel
の内容もindigo-devel
に混ぜ込んじゃっていいんですかね。demo/stable
ってブランチも気になる笑。
これには経緯があるのでご説明します.
indigo-devel
をつくりました.作成当時,indigo
の安定版ブランチを作っておかないとまずいなという話になると同時に,そろそろkinetic
にも移行したいという思いから,とりあえずindigo-devel
とkinetic-devel
をそれぞれ作り,ルートブランチをmaster
からindigo-devel
に変えました.ちなみに,master
ブランチは安定版として機能していなかった...orz
indigo-devel
を安定版にすべく,Travisのテストを遠そうとしましたが,industrial_ci
導入前のTravisのテストでrosdep
に問題があり,うまくTravisを通すことができないでいました.
さらに,industrial_ci
にチャレンジするも,こちらもテストに失敗するという躓きっぷりでした...
industrial_ci
については @MoriKen254 も良くご存知 & 超絶助けていただいている通りです.( #113 #117 を参照 )
indigo-devel
がうまく行かない(ビルドすら失敗することが多々あった)にもかかわらず,実験室でのデモを求められることが多かったので, @TakakiNishio により,demo/stable
ブランチが作られました.
demo/devel
について(憶測)上記までは僕が所属していた間の話です.demo/devel
については,名前から察するにdemo/stable
の開発版ブランチだと思います.
以上が経緯です...
で,結局どうするかという話ですが, @MoriKen254 のおかげでTravisのテストが通っているので,当初の設計どおりに行くなら,indigo
版はindigo-devel
へマージ,kinetic
版はkinetic-devel
にマージするのが良いと思います.研究室のメインのROSバージョンがどうなってるのか知らないのでindigo-devel
とkinetic-devel
のどちらをルートブランチにするのかは現役の方で決めて頂きたいです.
これは,個人的に思うことですが,現在は研究室メンバーそれぞれの開発をNishida-Labのリポジトリに直接ブランチを切ってCommitしています.これは,motoman_project
が始まった当初の開発人数が少なかった時には特に問題ないルールだったのですが,現在のように開発人数が増えてくるとブランチが増えすぎて機能しなくなるというのは想像に難くないと思います.
そこで,これまでは新入生の理解が複雑になるという理由でさけていたのですが,Nishida-Labのmotoman_project
をそれぞれのGithubアカウントでForkしてもらって,そこで開発を行ってもらい,研究室全体にとってマージすべきものをPRを出して管理するという,通常のGithubの使い方に則るのが良いと思います.
これについても,実際に行うのは現役の方々なので,そちらで決めてください!
以上,長くなりましたが,よろしくお願いします.
丁寧に対応いただき、ありがとうございます。
Setup Assistantの設定画面を見返したのですが、確かにGripper のAction定義とIKは無関係そうですね。失礼しました ^^; (いつもこんな感じで早とちりしてすみません汗。)
それとは別に、End Effectorという項目で、Grasping Frameを定義することで、把持位置についてIKが解けるっぽいじゃないかなと思っています。(多分フレームが追加されるだけなので、やってるんだろうなぁという意識ですが ^^;)
ひとまず、現状多大な工数をかけてグリッパ側のコントローラをMoveIt!対応させなくても、demoは可能そうですね。
こちらもよくわかりました。ずっとモヤモヤしていた感じですね ^^; ようやっと ci が通ったということで、見通しが立ちましたね。
やることはざっと下記のとおりですね。
とりあえずプルリク承認されたら、ci関連の残骸を一掃しましょう。
demo 関連も、プルリク承認後のindigo-develなら安定してビルドが通るはず。
てなわけで、demo/stable を indigo-develにマージして、demo/stableを削除。
demo/devel の正体を暴き、不要なら削除。必要な開発項目が残っていれば indigo-develにマージ。
これは、実機側に合わせるしかないですね。indigoのうちはindigo-devel, kineticに以降したらkinetic-develにする感じで。
これをどうするかは、おっしゃる通り現役メンバーで決めるべきですね。
おっしゃる通り、こちらは現役メンバーで決めることにしましょう。
ありがとうございます!
色々と遅くなり,申し訳ありません。 ひとまず本プルリクは承認させていただきます。 その上で下記項目については別のissueでの議論にさせていただきます。
現状のデモではgripperのコントローラは必要ないですが、近い将来必要になりそうです(その頃にはD-Handじゃないハンドになってるかも..?笑)
(demo/devel
は demo/stable
の開発ブランチでした。長い間マージしていませんでしたが、変更をdemo/stable
にマージしたのでdemo/devel
は削除しました。)
すみません、マージしてから閉じます。
Indigo版、Travis 通りましたので、プルリクです。
メインとなるルーチンに影響を与えていない認識ではあるのですが、マージする前に、動作確認お願いします。