Mori

I added a travis setting example on the branch `mk/add_travis_kinetic` by using `industrial_ci`. See the following sites for details. - github: https://github.com/Nishida-Lab/motoman_project/tree/mk/add_travis_kinetic - travis: https://travis-ci.org/Nishida-Lab/motoman_project/builds/334370929 ### NOTES In order to...

@thibaultbarbie Which do u think it's been still open or already covered by anyone else?

ありがとうございます！徐々に移行していきましょう！

まだよく分かりませんが、備忘録。 後述のPR2のグリッパにまつわる仕様に関して、リミッターに関わるクリティカルな変更があったようには見えず。。 また Gazebo のVer. が上がったことにより云々とかの話だと、面倒です汗。 ### action https://github.com/PR2/pr2_controllers/blob/kinetic-devel/pr2_gripper_action/src/pr2_gripper_action.cpp ### controller https://github.com/PR2/pr2_controllers/blob/kinetic-devel/pr2_mechanism_controllers/src/pr2_gripper_controller.cpp ### description https://github.com/PR2/pr2_common/tree/melodic-devel/pr2_description/urdf/gripper_v0 ## その他 actionでは、goalを受け取ると下記メッセージを発信する。 `pr2_controllers_msgs::Pr2GripperCommand` from https://github.com/PR2/pr2_controllers/blob/kinetic-devel/pr2_gripper_action/src/pr2_gripper_action.cpp ↓ controller がメッセージを受信し、effort指令値を計算しメッセージを発信する(`pr2_controllers_msgs::JointControllerState` なる、状態とか指令値とか色々入ったメッセージっぽい)。 https://github.com/PR2/pr2_controllers/blob/kinetic-devel/pr2_mechanism_controllers/src/pr2_gripper_controller.cpp ↓ Gazebo の場合、https://github.com/PR2/pr2_simulator/blob/kinetic-devel/pr2_gazebo_plugins/src/gazebo_ros_controller_manager.cpp が当該メッセージをハンドリングしている。（RobotHWSim...

良道くん、本件調査の続きを任せたいのですが、協力頂けませんか？ 弱音で申し訳ないのですが、そろそろ私一人では回らなくなってきましたので、助けて欲しいです笑。 その他頂いたコメント、エラッタ関係は、後ほど私がやりますので。取り急ぎ

ありがとう。目標はそれでおねがいします。 忙しいところ悪いね、任せた！月曜日の報告、とても楽しみにしています。 エラッタやるぞぉ。

ありがとう！現象はよく分かりました。 2000Nという値自体は気にはなっていましたが笑、ネット上のサンプルはどれもこんなもんだったので、いいんだろうと高をくくっていました。助かりました。 以下ただの思考実験です。 追求すると藪蛇になりそうですが、おそらくリミッタがちゃんと働くようになった、という感じですかね。そもそも2000Nなんて値を入れていたのにのほほんと動いている過去の挙動のほうが異常だったんですかね。 PR2自体の記述に変更がないので、コントローラのリミッタ部分がアップデートされたという感じ？ で、80Nに対応していないのは、そうなるようにコントローラのパラメータが最適化されていない。現状のパラメータだと高々14Nくらいでリミットがかかってしまう。みたいな感じ？だから参照するコントローラ用のlaunchファイルを自作する、という改善が提案されている？ そして、一回リミットオーバがかかったら、未来永劫復旧しない（再起動するまでは）。これは所望の仕様なのかちょっと判断しかねますね。その割に、13.5N以下というとても微妙な値を突っ込まないといけないというのは、辛い笑。PR2のIssueにあげてもいいかもしれないですね。 なんにせよ、色々ありがとう。ひとまずちゃんと動くようで、一旦スッキリしました！

PR2の件をIssueに上げるなら、 @RyodoTanaka くんの方が良いと思いますが、どうですか？ もし手が回らない等なら私が上げてもいいのですが、動画等含めせっかくの @RyodoTanaka くんの成果ですしね :)

ありがとうございます。状況を理解しました。藪蛇してしまった感じですかね笑。 - 開閉の指令値 - 闇ですねぇ。 - ここまで検証したのですから、Issue投げても迷惑がられないんじゃないかなー笑。 - ひっつく - 暗闇ですねぇ。 - ODEのシミュレーション演算部と描画状態の不一致が起きてしまってるんですかねぇ。分かりませんが。 前者と後者が全くの別問題なのか、いやはや実は同一の原因による問題で現象が異なるだけなのか、判断しかねますね。いずれにしても、現段階では独立したIssueとしてあげるのが妥当でしょう。 とりあえず前者についてはそれなりに調べたとは思うので、一旦Issueを投げて反応を見ながら、こっちからも必要に応じて情報出していく感じでいいんじゃないかなぁと思います。 そして、後者は確率的に起きるんですかね。 まったくの手探りで恐縮ですが、例えば、開閉時の力が強いとき、弱いとき、どっちのほうが発生する確率が高いとか、ありますかね（ODEの問題ならここに何らかの傾向が観察できないか？）。 あるいは、コップの代わりのコーラにしたら起きにくいとか（把持対象の形状がひっつきやすさに影響しないかとか？）。 もう少し温めた上で、以下の方針が取れるかと。 - 自己解決のパターン 1. 前者Issueとは別に、自分で検証しているうちに解決できたらラッキー。 1. 前者Issueの解決後に、後者も一緒に解決できたらラッキー。 - 他力本願のパターン 1. 前者Issueをやりながら関係がありそうだと思ったときに、情報提供として同一Issueに上げる。 1....

ありがとうございます。Issue投稿、素晴らしいですね！よろしくおねがいします。 あと、1:57 辺りで、確かに不自然な挙動が見られますね。自然落下ではなく、テーブルからの引力、あるいはハンドからの斥力、が働いているような。経緯から考えると、見た目にそぐわない余計な斥力(Collision領域がおかしくなって、カップと重複してしまっている？)が働いているのではないか？というこれまた憶測ですが。 それにしても、産総研（というか中岡さん）の誇る`Choreonoid`はスゴいんですね！`Gazebo`や`V-REP`と肩を並べる、日本発のスーパーシミュレータ！って感じで認知が広まるといいですね。