Fix travis indigo #120
Fix travis indigo #120
Conversation
|
ご指摘いただいた2件の不要な依存関係を除外し、Travisが通ることを確認しました。 どうでしょう。 |
|
今回のご変更で、catkin_make が通るようになりました！ |
|
ありがとう！助かります！（不備がまだまだ多く、ごめんなさい汗） あとは、実機もindigoのままかな？それなら、念の為実機で簡単に確認してみてもらって、問題がなければマージをお願いします。 |
|
実機での確認が大変遅くなり申し訳ありません。 下記のコマンドを別々のターミナルで実行し、Rviz上のインタラクティブマーカーで指定した手先位置に実機を動かす試験を行いました。 これらのコマンドは現在実機で運用している このエラーの原因は 変更点は、 この対処法は最適ではないと思いますが、似たようなエラーが |
|
@TakakiNishio さて、状況は理解しました。下記2つのファイルを比較し、現状の問題を解決する手段を見つけて、実機での動作を確認してみて下さい。 デフォルトで読んで動作している
|
|
ご返信ありがとうございます！ ご提案いただいたアドバイスを参考に、 実機で問題なく動作することが確認できましたので、こちらも |
|
ありがとうございます！実機での動作確認も、いいですね。 072ad0e を確認しました。 念の為確認ですが、以下のgripper側のコントローラの対応は不要でしょうか？launchファイルの名称を見る限り、dhandに対応していると思われるので。せめてfakeぐらい入れておく必要は？ もし不要であればこのままマージ、必要であれば対応してからマージとしましょう。一回ご自身で調べて判断してみてもらえますか？ 8月中で様子を見て、やっぱり不要と言うことであれば、マージしてしまいましょう。 判断基準は？
たとえば、gripper 側のコントローラをちゃんと設定しないと、MoveItと連携する上で何かできなくなってしまうことはないか？等 私は実装者ではないのではっきり回答できないのですが、実績的には問題ないのかなーと、思っています。 ちょっと調べてみたこれを見ると、一応gripperのコントローラが定義されているようですね。arm用で言うところの これはoptionalだと、こちらにも記載されているようですしね。 一応motomanの他のconfigをざっと見てみたのですが、jammingについても 運用上は、プランニングを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 経緯と理由ジャミンググリッパ通常のピッキング（チャックで挟むようなピッキングを指す）を行うことができなかったため，コントローラを設計しませんでした． D-HandD-Handは閉リンク機構を有しているためURDFに記述できず，仮にコントローラを設計したとしてもその開閉をうまく反映できないので，設定していません． コントローラを設計しないメリット
設定しないことによるデメリット
以上です．よろしくお願いします． |
|
すみません． |
|
仮にD-Handのグリッパコントローラを設計するのであれば
上記の２つをaction messageを介して行ってくれるようなドライバを作成する必要があるかと思います． modbus ってそもそも何？というのはググればわかりますが，大雑把に言うと FA機器に広く使われている通信規格みたいなもんです． 以上，補足でした． |
|
詳細なご解説、ありがとうございます！ 閉リンクが絡んでいて、色々厄介なことがよくわかりました。 理解の確認そして、現状のシステムにおいて、dhandが初期状態以外の開き具合だと、MoveIt側が現実の情報を把握できないために、例えば障害物回避ができない可能性がありそうですね。 それを解決するためには、アクチュエータの位置に合わせて他のJointの現在値を仮想的に計算して 順運動学はそれで良さそうな気がします。この状態を action を介してIAIドライバに司令を送るdriverノードが必要なことも、よく分かりました。 以上を統合したMoveIt対応ROS パッケージを完成させようとしたら、それなりのパワーが必要ですね。 これまでは、dhandの開閉状態を評価しなければならないほどシビアな判定を要するデモもなく、まずは動作させることを優先する必要があったという経緯もあったでしょう。詳細な仕様を意識しすぎてデモができないのでは、元も子もありませんからね。現状のパッケージ構成となっている理由が良く分かりました。 情報がクリアになりました。ありがとうございます。 マージについてまず本プルリクはマージし、当該案件はIssueとして残しておいて、必要となったとき or 趣味で対応するようにして良さそうですね（デイタイムにlab常駐してフルコミットできるなら、私でもいくらでも実装したいのですが…笑 😭 ）。 ブランチの整理質問ついでですが、 というのも、最近ブランチが増えてしまったので、整理したいなと。本件も一旦本プルリクをマージした後、別Issueにしようと思います。 |
IKについての質問
これは単純な質問なんですが，Gripper部分もMoveit!はIKを解いてくれるんですかね？ ブランチについて
これについては， @Ry0 もSlackでちょいちょい気にしてました笑
これには経緯があるのでご説明します． 1. まず
|
|
丁寧に対応いただき、ありがとうございます。 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 についておっしゃる通り、こちらは現役メンバーで決めることにしましょう。 ありがとうございます！ |
|
色々と遅くなり，申し訳ありません。 D-hand の IK について現状のデモではgripperのコントローラは必要ないですが、近い将来必要になりそうです（その頃にはD-Handじゃないハンドになってるかも..？笑） ブランチ整理についてルートブランチ・Fork について（ |
|
すみません、マージしてから閉じます。 |
Indigo版、Travis 通りましたので、プルリクです。
メインとなるルーチンに影響を与えていない認識ではあるのですが、マージする前に、動作確認お願いします。