launch test が通らない

[MoriKen254]

先程は早急なご対応、ありがとうごいます！ ^^

題記の通り、testが通らなくなりましたので、issueにします。

test 抜粋

FAILURE:
[/home/masa/ros/motoman_ws/src/motoman_project/motoman_moveit/test/sia5_with_kinectv2_moveit_planning_execution_launch_test.xml]:
    unused args [sensor_max_range, srdf_model, load_robot_description, kinematics_config, joint_limits_config, octomap_frame_name, sensor_config, octomap_resolution_value, urdf_model, use_depth_sensor] for include of [/home/masa/ros/motoman_ws/src/motoman_project/motoman_sia5_moveit_config/launch/move_group.launch]

ざっとソースコードを見ただけなのですが、 「/home/masa/ros/motoman_ws/src/motoman_project/motoman_sia5_moveit_config/launch/move_group.launch」 内の修正によるものと考察します。

従来はmove_group.launch 内で、各パラメータを引数で定義して、その引数をplanning_context.launchに渡すという構成でした。上位でパラメータを変えれば、それに従って低レイヤーが切り変わってくれる、という感じです。

変更後は、move_group.launchでは引数を排除し、planning_context.launch 内に直接パラメータを入力するという構成をとるように変更がされている、と解釈しています。

これは、indigo版で作成したコードは「motoman_moveit_config」というパッケージでそれらの設定パラメータを管理していたところ、kinetic版ではそのパッケージが欠落しているための措置と、推察しています。

これにより、move_group.launch を呼ぶさらに上位の「sia5_moveit_planning_context.launch」等を利用することを前提としたこのリポジトリのポリシーとの齟齬が起こっている、というのが現状です。

@RyodoTanaka くんにもご意見をいただけるととっても嬉しいです ^^

testを通すだけなら、更に上位のlaunchまですべて現行のシステムに合わせて書きなおすことで対策もできるのですが、低レイヤーの修正によってアプリケーションレイヤーの修正が必要なるというのは、ちょっと今後大変になるのかな、と感じて、投稿してみました ^^; すみません。

老婆心なのかもしれませんが、長期的に運用することを考えると、現行の対策を行うより、kinetic-develにも「motoman_moveit_config」復活させるほうが、良いのかな、と考えています。

• 理由1. 従来のアプリケーションの資産がそのまま利用できる
• 理由2. planning_context.launch に直接urdf等を設定することはハードコーディングとなり、プログラムの汎用性が下がります。たとえば、motomanのアプリケーションをdensoさんのロボットに転用したいとなったとき、ROSのうまみが低減してしまうかな、と思います。

今ならまだ変更範囲が少ないので、ご検討いただければ幸いです。

[MoriKen254]

ご報告

お待たせしてしまいました。CI 上で念願の（←私だけ？笑）Kinetic版のmotoman_projectの launch テストが通る状態まで復旧しました。gitlab-ci/kinetic-devel ブランチです。

解決方法

ついでに、Travis CI (industrial_ci) ではどうしてもcatkin buildが通らなかったので、gitlab-ciでテストを通しました（現行のROS対応CIのうち、唯一catkin_makeが通るプラットフォームなので）。

原因

主な原因はar_tools内artoolkitパッケージのややこしい構成であり汗。industrial_ciだと catkin buildしか選択肢がないのですが、これはcatkin_make_isolatedをしております。

しかし、artoolkit はこれを前提としたパッケージになってない汗。だから、catkin_make_isolatedで独立構成されると、ar_poseがartoolkitを認識できない。

そこを解決できないかと色々試してみたのですが、よく分からず諦めました笑。catkin_makeなら別に問題ないので。

ゴチャゴチャし始めたので、仕組みは追ってWikiに掲載しますね。だれかCMake詳しい人がいい感じに直してくれたら、Travis CI にもワンチャンあり。

運用

変更先リポジトリ

変更は今までどおりGitHubでOKです。CI ビルドについてはGitLabへミラーリングしたリポジトリ上で行う構成です。

取り急ぎ、現状は私のGitLabアカウントを使っていますが、ゆくゆくはNishidaLabのアカウントを使えるようにしたいですね。

ブランチ

gitlab-ci/kinetic-develをご確認ください。 ↓ https://github.com/Nishida-Lab/motoman_project/tree/gitlab-ci/kinetic-devel

これで様子を見て、安定したらこのブランチをkinetic-develにリネームして運用に移るとよいかな、と思います。

その後の運用

変更の際は、gitlabの下記ページを参照し、該当するブランチのCIビルドが通ったことを確認した上で、Merge することをオススメします。

https://gitlab.com/MoriKen254/motoman_project/tree/gitlab-ci/kinetic-devel

動作検証

Kinetic 上でのMoveit! の動作検証

下記コマンドを別シェルで順に実行し、プランニング動作ができるところまでを、当方のローカル環境(ubuntu 16.04 ROS Kinetic)で確認しました。

Gazebo

roslaunch motoman_gazebo sia5_sia5_empty_world.launch

Moveit!

roslaunch motoman_moveit sia5_moveit_planning_execution.launch

エラーが見えたかも…

RViz側のシェルでSemantic description is not specified for ...的なエラーがチラッと見えるのですが、そこの解決はトライしてみてください笑。困ったら遠慮なくIssueの上げてください。一緒に解決していきましょう。

ご参考

以下のWikiもご確認ください。設計思想が垣間見えます。 分からないことがあって困ったら、先輩の @Ry0 くんとか @RyodoTanaka くんが助けてくれると思います。多分私も首を突っ込むと思います笑。勉強させてください。

https://github.com/Nishida-Lab/motoman_project/wiki/Motion-planning-for-Real-robot-and-Gazebo-simulation-robot-%5BJapanese%5D

[MoriKen254]

CI ビルドの確認は、こちらのGitHub側のコミットログからでも確認できるようです。GitHubとGitLabはコンペチタのようですが、お互いよく連携できているようですね :smiley:

今回の対応で私が学んだことをWikiに記載したら、本Issueを閉じることとします。

皆さん、ご意見等ございましたら、よろしくおねがいします。

[130s]

Travis CI (industrial_ci) ではどうしてもcatkin buildが通らなかったので

ログを見ていないのではっきりとは分かりませんが，現象だけ見るとよくあるトラブルで，concurrency を CATKIN_PARALLEL_JOBS で -p1 等に下げる通ります．

[MoriKen254]

@130s ご無沙汰しております。コメント、本当にありがとうございます。メンテナに助けていただけると、大変ありがたいです。

ビルド負荷の大きい数値計算系のC++プログラムをコンパイルする際は、リソース不足でTravisが強制終了することは、当方も何度も経験しております。ゆえに、そのオプションでリソースの問題を解決すればTravisが落ちずにビルドが通るというのは把握しており、既に本リポジトリの.travis.ymlでのオプションに加えられています。

https://github.com/Nishida-Lab/motoman_project/blob/fix-kinetic-devel-2/.travis.yml

    - CATKIN_PARALLEL_TEST_JOBS=-p1
    - ROS_PARALLEL_TEST_JOBS=-j1

ただ、今回はCMakeListsの構成の話になっていると考えています。

背景が長くて恐縮ですが、ざーっと説明しますので、ご助言を頂ければありがたいです。

前提

問題となっているパッケージは ar_toolsです。 この中に、「artoolkit」と「ar_pose」というパッケージがあります。 「ar_pose」は「artoolkit」に依存しており、その設定は「ar_pose」側の「package.xml」と「CMakeLists.txt」に記載されています。

現象

「catkin build」をする際に、「artoolkit」のビルドが完了した後に「ar_pose」のビルドが始まっても、「artoolkit」を本当にコンパイルしたの？と怒られます。したのに怒られているのですから、設定不足で見つけることができていないんだと思います。

...............................................................................
Finished  <<< artoolkit                            [ 17.5 seconds ]
Starting  >>> ar_pose                             
_______________________________________________________________________________
Errors     << ar_pose:cmake /root/catkin_ws/logs/ar_pose/build.cmake.000.log
CMake Error at /root/catkin_ws/install/share/artoolkit/cmake/artoolkitConfig.cmake:148 (message):
  Project 'ar_pose' tried to find library 'ARgsub'.  The library is neither a
  target nor built/installed properly.  Did you compile project 'artoolkit'?
  Did you find_package() it before the subdirectory containing its code is
  included?
Call Stack (most recent call first):
  /opt/ros/kinetic/share/catkin/cmake/catkinConfig.cmake:76 (find_package)
  CMakeLists.txt:6 (find_package)

当方が個人的に色々いじったminimal なリポジトリで検証したログがこちらです。（リポジトリ自体は相当汚くなってしまいましたが汗。）

解析

ただ、これはcatkin_make をした場合には起こりません。catkin_make をすればとりあえずモジュールがdevel スペースに入ってくれるから、find_package()で引っかかってくれるのかな、と解釈しています。

一方、catkin build をする場合、devel/.private/ 以下にモジュールが入ると認識しています。それでもdevel 以下にそのモジュールへのシンボリックリンクがあるところまでは確認できたのですが、少なくとも現状のCMakeLists.txtの設定ではうまく見つけられていないみたいです。

そこで、artoolkit をビルドしたときに、明示的にInstallすれば、ar_poseが見つけてくれるのかな？と言う仮説を立て、artoolkit側のCMakeLists.txtを編集して色々試してみたのですが、よくわからなくなってしまいました。

artoolkit はもともとサードパーティのオープンソースです。このCMakeLists.txtの中では、独自にConfiture → make をしているようで、catkinのシステムを介してビルドしているように見えないのです。 ↓ https://github.com/ar-tools/ar_tools/tree/master/artoolkit

一応モジュールを手動でdevel/lib にコピーしているようなのですが、明示的にInstallはしていません。この辺りの構成が、catkin_makeでうまくいくのに、catkin build では失敗してしまっている原因なのではないかな？と考えました。

そこで、Installを試みて色々やってみたのですが、ar_poseが認識するフォーマットを見つけることができませんでした。artoolkit パッケージがcatkinのCMakeLists.txt に準拠してくれていれば、ROS Wiki通りにやればInstallされるとは思うのですが、特殊な構成になっているせいか教科書通りには中々行きませんでした。

当方がCmakeに明るくないという問題もあり、散々悩んで挙げ句どうしても解決できないので、catkin_make に逃げたという経緯がありました。私の考えが間違っているかもしれません。

ここまでの流れが複雑で申し訳ないのですが、ご助言頂ければ幸いです。

[MoriKen254]

あ、失礼しました。jobのスレッド落としていたのは、TESTだけでした汗。でも、問題の本質はそこではなさそうです。ローカルでも同様のエラーが出てcatkin buildが失敗しましたので。

[130s]

ぜんぶ見きれていませんが，

CMake Error at /root/catkin_ws/install/share/artoolkit/cmake/artoolkitConfig.cmake:148 (message):
  Project 'ar_pose' tried to find library 'ARgsub'.  The library is neither a
  target nor built/installed properly.  Did you compile project 'artoolkit'?

これは cmake が ARgsub を見付けられてないという状況と思います．並行でビルドを強行する catkin_tools が当該 package のビルドが，必要とされた時点でまだ終わってなかったから，というのがよくある状況です．これは CI に限らずローカルでも起こります．

[MoriKen254]

ありがとうございます。スレッド数を落とすのは、リソースだけではなく、シーケンスの問題も解決すること、よくわかりました。

その上で、以下のオプションを加えてみたのですが、同じエラーが出ました。

- CATKIN_PARALLEL_JOBS=-p1

https://travis-ci.org/Nishida-Lab/motoman_project/jobs/409919733

Setting environment variables from .travis.yml
$ export CATKIN_PARALLEL_JOBS=-p1

Errors     << ar_pose:cmake /root/catkin_ws/logs/ar_pose/build.cmake.000.log
CMake Error at /root/catkin_ws/install/share/artoolkit/cmake/artoolkitConfig.cmake:148 (message):
  Project 'ar_pose' tried to find library 'ARgsub'.  The library is neither a
  target nor built/installed properly.  Did you compile project 'artoolkit'?
  Did you find_package() it before the subdirectory containing its code is
  included?
Call Stack (most recent call first):
  /opt/ros/kinetic/share/catkin/cmake/catkinConfig.cmake:76 (find_package)
  CMakeLists.txt:6 (find_package)

[MoriKen254]

https://travis-ci.org/Nishida-Lab/motoman_project/jobs/409919733

のログでちょっと気になるのが、1434行目で

Finished  <<< artoolkit                                   [ 18.7 seconds ]

と、確かにartoolkitのビルドが完了しているログがあるのに、最後の総括のところ、1510行目以降

[build] Successful packages:

 [   Ignored] ar_tools                    
 [Successful] dhand_control               
 [Successful] dhand_description           
 [Successful] dhand_driver                
 [Successful] dhand_msgs                  
 [   Ignored] dhand_ros_pkg               
 [   Ignored] iai_kinect2                 
 [Successful] kinect2_registration        
 [   Ignored] motoman                     
 [Successful] motoman_cable_removal       
 [Successful] motoman_description         
 [Successful] motoman_gripper             
 [Successful] motoman_msgs                
 [Successful] motoman_viz_msgs           

[build] Failed packages:

 [    Failed] ar_pose                     

[build] Abandoned packages:

 [ Abandoned] dhand_gazebo                
 [ Abandoned] kinect2_bridge              
 [ Abandoned] kinect2_calibration         
 [ Abandoned] kinect2_viewer              
 [ Abandoned] motoman_control             
 [ Abandoned] motoman_demo                
 [ Abandoned] motoman_driver              
 [ Abandoned] motoman_euclidean_cluster   
 [ Abandoned] motoman_gazebo              
 [ Abandoned] motoman_mh5_support         
 [ Abandoned] motoman_moveit              
 [ Abandoned] motoman_sda10f_moveit_config
 [ Abandoned] motoman_sda10f_support      
 [ Abandoned] motoman_sia10d_support      
 [ Abandoned] motoman_sia10f_support      
 [ Abandoned] motoman_sia20d_moveit_config
 [ Abandoned] motoman_sia20d_support      
 [ Abandoned] motoman_sia5_moveit_config  
 [ Abandoned] motoman_sia5d_support       
 [ Abandoned] motoman_viz        

で、artoolkitの表示がどこにもないということです。

「Successful」にも「Ignored」にも「Failed」にも「Abandoned」にもなっていないというのは、健全ではないと思います。

こういう経緯から、特殊なCMakeLists.txtの構成を取るartoolkitはcatkinから見放されてしまっている（packageとして登録されていない？）のではないか？という考えに至ったという背景があります。

catkinの中身を知らない人間が言っているので間違っているかもしれませんが、気になる現象ですので、参考になればと思います。

[MoriKen254]

ようやくindustrial_ci で通せました！

https://travis-ci.org/Nishida-Lab/motoman_project/jobs/412294270

チェックが厳しい分、あるべき姿を勉強できました。catkinの理解が深まりました。gitlab-ci は卒業します笑。

正直、色々な問題がからみ合っていて、様々な観点から修正したのですが、一番大切なことはindustrial_ciでlaunchテストをする際に明示的なInstallが必要だというです。

CMakeLists.txt でモジュールについて下記の記述をしないと、他パッケージから呼び出すことができないことが分かりました。

foreach(module hoge1 hoge2 hoge3)
  install(TARGETS ${module}
    ARCHIVE DESTINATION ${CATKIN_PACKAGE_LIB_DESTINATION}
    LIBRARY DESTINATION ${CATKIN_PACKAGE_LIB_DESTINATION}
    RUNTIME DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION}
  )
endforeach(dir)

ローカルだとcatkin buildで自動的にbuild\lib以下にシンボリックリンクが入るのですが、industrial_ciの環境ではそうはなっていないようです。これに甘んじていたから通らなかったようです汗。

その他、launchテストの粒度もローカルでcatkin run_testsをするよりずっと厳しくて、依存パッケージの欠落等でもかなり厳しくお叱りを受けました笑。おかげで、packageの設定が洗練されたかなと思います。

あとはデバッグの残骸を綺麗にしたり、package.xmlのformatを2にしてすっきりさせたり、細かいところを仕上げてOKとしようと思います。

ありがとうございました。

[130s]

8888!

ar_tools のビルド法がおかしいという件 https://github.com/Nishida-Lab/motoman_project/issues/117#issuecomment-408906377 ，みてみたら CI 上で catkin_tools でビルドしてそうだし，おかしいなと思ったら，Travis CI が有効になってないようなので，そのせいで下流で苦しんでいる方がいると伝えてみました https://github.com/ar-tools/ar_tools/issues/23

industrial_ciでlaunchテストをする際に明示的なInstallが必要だというです。

はい，industrial_ci では，単純にソフト開発の良い姿勢だということで，install スペースをデフォルトにしてます (CATKIN_CONFIG 変数で --no-install としてやれば変えられます)． https://github.com/ros-industrial/industrial_ci/blob/master/doc/index.rst#what-are-checked

[MoriKen254]

ありがとうございます。やや強引ですが、ざっくり下図のような対策です。

そもそもARToolKitをcatkinとしてビルドすることのほうが違和感があって。OpenCVとかPCLと同じく3rd-Partyなのだから、あまりここをcatkinizeすることにパワーを割くのは得策ではないと判断しました。 ビルドのたびにSVNからダウンロードするという構成のも、何かモヤっとしまして。

ARToolKit自体収束方向（？）に見えまして、ビルドモジュールをDebianパッケージで固めてもあまり害はないかと思いまして。CIでの作業時間も短縮されます。

あとで @130s さんが立ててくださった本家のIssueにも、本件を上げてみようかなと思います。

[MoriKen254]

forkしたar_toolsパッケージで、ひとまずindustrial_ciの空間でbuildとtestを通しました。 ↓コレ https://github.com/MoriKen254/ar_tools/tree/w/o_artoolkit

https://github.com/ar-tools/ar_tools/issues/23 に、今回の修正についてコメントを出しました。

当方自身、ソフトウェアについては無知で、不格好・無作法な所が多々あり大変恐縮ですが、先方のご意見、ご鞭撻等を受けながら、できるだけ多くのユーザーの皆様にとって有益なパッケージとなるよう、切に望んでおります。

少し、反応を拝見した上で、良い落とし所に導かれよう、一緒に考えられればと思います。

[MoriKen254]

もう長らくメンテされていない模様です。現行は下記パッケージですし、深入りせずこれにてクローズで良いと判断します。

https://github.com/ros-perception/ar_track_alvar

クローズ！