Nishida-Lab / motoman_project

Repository for Motoman ROS applications
http://lab.cntl.kyutech.ac.jp/~nishida/en/research-en.html
52 stars 32 forks source link

Fix travis indigo #120

Closed MoriKen254 closed 6 years ago

MoriKen254 commented 6 years ago

Indigo版、Travis 通りましたので、プルリクです。

メインとなるルーチンに影響を与えていない認識ではあるのですが、マージする前に、動作確認お願いします。

TakakiNishio commented 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 が通っているということは私の環境に間違いがあるのでしょうか..? お力になれず申し訳ありません。。

MoriKen254 commented 6 years ago

レスありがとうございます!^^ 私もここでの議論を通して、皆さんとともに勉強させてもらえれば幸いです。

とりあえず、前者のmotoman_moveitが見つからないのは、CMakeLists.txtfind_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

よろしくお願いいたいます。

TakakiNishio commented 6 years ago

ご返信ありがとうございます。

ご教示いただいたコマンドをすべて実行しても、 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
MoriKen254 commented 6 years ago

試しに、

motoman_project/motoman_demo/CMakeLists.txt

のfind_packageからar_poseを除外した上でcatkin_makeしてみてもらえますか?

TakakiNishio commented 6 years ago

motoman_demo の CMakeLists.txt から ar_pose を除外すると catkin_make は通りました..

MoriKen254 commented 6 years ago

ご指摘いただいた2件の不要な依存関係を除外し、Travisが通ることを確認しました。

どうでしょう。

TakakiNishio commented 6 years ago

今回のご変更で、catkin_make が通るようになりました! 2つのPCで確認できたので、大丈夫かと思われます。

MoriKen254 commented 6 years ago

ありがとう!助かります!(不備がまだまだ多く、ごめんなさい汗)

あとは、実機もindigoのままかな?それなら、念の為実機で簡単に確認してみてもらって、問題がなければマージをお願いします。

TakakiNishio commented 6 years ago

実機での確認が大変遅くなり申し訳ありません。 実機は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_configmoveit_planning_execution.launch のdefaultから設定するようにした点です。

この対処法は最適ではないと思いますが、似たようなエラーが indigo-devel ブランチでも発生するため、何らかの対策が必要かと思われます..

MoriKen254 commented 6 years ago

@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

以下、私の所感。参考程度に。

<!-- <arg name="controllers_config" value="$(find motoman_moveit)/config/sia5_with_dhand/fake_controllers.yaml"/> -->

取り急ぎ。

TakakiNishio commented 6 years ago

ご返信ありがとうございます!

ご提案いただいたアドバイスを参考に、takaki/fix-travis-indigoブランチにおいて変更 072ad0e を加えました。

実機で問題なく動作することが確認できましたので、こちらもfix-travis-indigoブランチにマージしてよろしいでしょうか?

MoriKen254 commented 6 years ago

ありがとうございます!実機での動作確認も、いいですね。

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側のコントローラの情報は下記ファイルが参考になるのかなと思っています。

RyodoTanaka commented 6 years ago

@MoriKen254 @TakakiNishio gripperのコントローラですが,設定していません.経緯と理由は以下のとおりです.

経緯と理由

ジャミンググリッパ

通常のピッキング(チャックで挟むようなピッキングを指す)を行うことができなかったため,コントローラを設計しませんでした.

D-Hand

D-Handは閉リンク機構を有しているためURDFに記述できず,仮にコントローラを設計したとしてもその開閉をうまく反映できないので,設定していません. また,仮に設定するのであれば,実際の開閉に使用されている位置決めサーボモータ(IAIのやつ)のjointを新たにURDFに記述し,そこにコントローラを設定する必要があります.

コントローラを設計しないメリット

設定しないことによるデメリット

以上です.よろしくお願いします.

RyodoTanaka commented 6 years ago

すみません. 間違って閉じてしまいました...orz

RyodoTanaka commented 6 years ago

仮にD-Handのグリッパコントローラを設計するのであれば

上記の2つをaction messageを介して行ってくれるようなドライバを作成する必要があるかと思います. modbusについては,Pythonライブラリの minimalmodbusというのを使って制御してあります. minimalmodbusについてわからなければ, @thibaultbarbie がdhand_driverを作ってくれた人なので,聞いてみると良いと思います(英語のリファレンスも用意してくれてたので,とりあえずもらって読んでみると良いと思います). 逆に,Pythonでしか実装していないので,C++で実装する必要が出てくると,modbus の C++ライブラリを探してくるところからやる必要があります.

modbus ってそもそも何?というのはググればわかりますが,大雑把に言うと FA機器に広く使われている通信規格みたいなもんです.

以上,補足でした. よろしくお願いします.

MoriKen254 commented 6 years ago

詳細なご解説、ありがとうございます!

閉リンクが絡んでいて、色々厄介なことがよくわかりました。

理解の確認

そして、現状のシステムにおいて、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/develindigo-develの違いがあるみたいですけど、demo/develの内容もindigo-develに混ぜ込んじゃっていいんですかね。demo/stableってブランチも気になる笑。

というのも、最近ブランチが増えてしまったので、整理したいなと。本件も一旦本プルリクをマージした後、別Issueにしようと思います。

RyodoTanaka commented 6 years ago

@MoriKen254

IKについての質問

順運動学はそれで良さそうな気がします。この状態をjoint_statesにさえ送っておけば、グリッパとアーム先端間の逆運動学もMoveIt側に任せても大丈夫、なんだと思っています。

これは単純な質問なんですが,Gripper部分もMoveit!はIKを解いてくれるんですかね? Moveit! setup assistant で設定する際に,D-Handの手先まで Arm グループに入れてしまえばできるとは思うのですが,それはMoveit!の設計趣旨違うと思ってます. なので,仮にMoveit!対応のD-Handコントローラを仮に設計したとしても,D-Hand部分についてはIKは解いてくれないものと考えてました.

ブランチについて

最近ブランチが増えてしまったので、整理したいなと

これについては, @Ry0 もSlackでちょいちょい気にしてました笑 僕も気にはなってたんですが,かと言って僕らが口を出して現役の方の混乱を生むのの良くないなと思ってたんで,研究室所属の方にお任せしたいと思ってます.

demo/develindigo-develの違いがあるみたいですけど、demo/develの内容もindigo-develに混ぜ込んじゃっていいんですかね。demo/stableってブランチも気になる笑。

これには経緯があるのでご説明します.

1. まずindigo-develをつくりました.

作成当時,indigoの安定版ブランチを作っておかないとまずいなという話になると同時に,そろそろkineticにも移行したいという思いから,とりあえずindigo-develkinetic-develをそれぞれ作り,ルートブランチをmasterからindigo-develに変えました.ちなみに,masterブランチは安定版として機能していなかった...orz

2. 安定版ブランチで躓く

indigo-develを安定版にすべく,Travisのテストを遠そうとしましたが,industrial_ci導入前のTravisのテストでrosdepに問題があり,うまくTravisを通すことができないでいました. さらに,industrial_ciにチャレンジするも,こちらもテストに失敗するという躓きっぷりでした... industrial_ciについては @MoriKen254 も良くご存知 & 超絶助けていただいている通りです.( #113 #117 を参照 )

3. とりあえずの安定版ブランチが必要になる

indigo-develがうまく行かない(ビルドすら失敗することが多々あった)にもかかわらず,実験室でのデモを求められることが多かったので, @TakakiNishio により,demo/stableブランチが作られました.

4. demo/develについて(憶測)

上記までは僕が所属していた間の話です.demo/develについては,名前から察するにdemo/stableの開発版ブランチだと思います.

以上が経緯です... で,結局どうするかという話ですが, @MoriKen254 のおかげでTravisのテストが通っているので,当初の設計どおりに行くなら,indigo版はindigo-develへマージ,kinetic版はkinetic-develにマージするのが良いと思います.研究室のメインのROSバージョンがどうなってるのか知らないのでindigo-develkinetic-develのどちらをルートブランチにするのかは現役の方で決めて頂きたいです.

そもそものブランチルールを変える時に来ているのかもしれない...

これは,個人的に思うことですが,現在は研究室メンバーそれぞれの開発をNishida-Labのリポジトリに直接ブランチを切ってCommitしています.これは,motoman_projectが始まった当初の開発人数が少なかった時には特に問題ないルールだったのですが,現在のように開発人数が増えてくるとブランチが増えすぎて機能しなくなるというのは想像に難くないと思います. そこで,これまでは新入生の理解が複雑になるという理由でさけていたのですが,Nishida-Labのmotoman_projectをそれぞれのGithubアカウントでForkしてもらって,そこで開発を行ってもらい,研究室全体にとってマージすべきものをPRを出して管理するという,通常のGithubの使い方に則るのが良いと思います. これについても,実際に行うのは現役の方々なので,そちらで決めてください!

以上,長くなりましたが,よろしくお願いします.

MoriKen254 commented 6 years ago

丁寧に対応いただき、ありがとうございます。

IKについて

Setup Assistantの設定画面を見返したのですが、確かにGripper のAction定義とIKは無関係そうですね。失礼しました ^^; (いつもこんな感じで早とちりしてすみません汗。)

それとは別に、End Effectorという項目で、Grasping Frameを定義することで、把持位置についてIKが解けるっぽいじゃないかなと思っています。(多分フレームが追加されるだけなので、やってるんだろうなぁという意識ですが ^^;)

ひとまず、現状多大な工数をかけてグリッパ側のコントローラをMoveIt!対応させなくても、demoは可能そうですね。

ブランチの整理

こちらもよくわかりました。ずっとモヤモヤしていた感じですね ^^; ようやっと ci が通ったということで、見通しが立ちましたね。

やることはざっと下記のとおりですね。

fix ci 周りの残骸をお掃除

とりあえずプルリク承認されたら、ci関連の残骸を一掃しましょう。

demo 関連ブランチの整理

demo 関連も、プルリク承認後のindigo-develなら安定してビルドが通るはず。

てなわけで、demo/stable を indigo-develにマージして、demo/stableを削除。

demo/devel の正体を暴き、不要なら削除。必要な開発項目が残っていれば indigo-develにマージ。

ルートブランチ

これは、実機側に合わせるしかないですね。indigoのうちはindigo-devel, kineticに以降したらkinetic-develにする感じで。

これをどうするかは、おっしゃる通り現役メンバーで決めるべきですね。

Fork について

おっしゃる通り、こちらは現役メンバーで決めることにしましょう。

ありがとうございます!

TakakiNishio commented 6 years ago

色々と遅くなり,申し訳ありません。 ひとまず本プルリクは承認させていただきます。 その上で下記項目については別のissueでの議論にさせていただきます。

D-hand の IK について

現状のデモではgripperのコントローラは必要ないですが、近い将来必要になりそうです(その頃にはD-Handじゃないハンドになってるかも..?笑)

ブランチ整理について

ルートブランチ・Fork について

demo/develdemo/stable の開発ブランチでした。長い間マージしていませんでしたが、変更をdemo/stable にマージしたのでdemo/develは削除しました。)

TakakiNishio commented 6 years ago

すみません、マージしてから閉じます。