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

pythonのmoveit API でうまく行かなかったとかの件 #53

Closed MoriKen254 closed 8 years ago

MoriKen254 commented 8 years ago

python でmoveit API を使って動かそうとしたら、うまく行かない?的な話があったと思います。初回はうまく行くけど、二点目で不自然な挙動を示す、的な。原因を突き止めたいですね。

コードはこれでしょうか? https://github.com/Nishida-Lab/motoman_project/blob/master/motoman_moveit/scripts/moveit_command_sender.py

この現象を再現するまでの手順と、現象に関する具体的な説明をいただけますか?

Ry0 commented 8 years ago

はい コードはリンクの通りです. 元ソースは http://daikimaekawa.github.io/ros/2014/06/08/ROSNextage02/ です. これを実行するだけでは当然うまくいかないので,このソースを小分けにして検証を行った結果,うまく実行できていない現状です.

#!/usr/bin/env python

import moveit_commander
import rospy
import geometry_msgs.msg
import copy

def main():
    rospy.init_node("moveit_command_sender")

    robot = moveit_commander.RobotCommander()

    print "=" * 10, " Robot Groups:"
    print robot.get_group_names()

    print "=" * 10, " Printing robot state"
    print robot.get_current_state()
    print "=" * 10

    arm = moveit_commander.MoveGroupCommander("arm")

    print "=" * 15, " Arm ", "=" * 15
    print "=" * 10, " Reference frame: %s" % arm.get_planning_frame()

    print "=" * 10, " Reference frame: %s" % arm.get_end_effector_link()

    arm_initial_pose = arm.get_current_pose().pose
    print "=" * 10, " Printing initial pose: "
    print arm_initial_pose

    target_pose = geometry_msgs.msg.Pose()

    target_pose.position.x = 0.5
    target_pose.position.y = -0.25
    target_pose.position.z = 0.5
    target_pose.orientation.x = 0.0
    target_pose.orientation.y = 0.0
    target_pose.orientation.z = 0.0
    target_pose.orientation.w = 1.0
    arm.set_pose_target(target_pose)

    print "=" * 10, " plan1..."
    arm.go()
    rospy.sleep(1)

    print "=" * 10, " Planning to a joint-space goal"
    arm.clear_pose_targets()
    print "=" * 10, " Joint values: ", arm.get_current_joint_values()

if __name__ == '__main__':
    try:
        main()
    except rospy.ROSInterruptException:
        pass

とりあえず元ソースの第一フェーズである,手先の位置姿勢を与えて,その間の軌道を補間するということをやっています.

launchしたものは以下の通りです.

roslaunch motoman_gazebo sia5_empty_world.launch
roslaunch motoman_sia5_moveit_config move_group.launch 
rosrun motoman_moveit moveit_command_sender.py 

これでボロボロですが,なんとか一旦Gazebo上で動きを見せてくれます.

screenshot from 2016-02-02 20 41 31

ですがmoveit_command_sender.pyにて以下のようなエラーでコアダンプするため,そもそも問題のあるコードです.

terminate called after throwing an instance of 'class_loader::LibraryUnloadException'
  what():  Attempt to unload library that class_loader is unaware of.
中止 (コアダンプ)

これだけでも十分問題なのですが,この状態で再び異なる手先位置に書き換えたPythonコードを実行すると,現在の姿勢からのプランニングではなく,初期姿勢からのプランニングになってしまっています...

これはMoveitのプラグイン上で,インタラクティブマーカーで手先位置を動かして,Plan and Execute→Plan and Execute(初期姿勢ではない姿勢から,2回目以降)を実行しても起きてしまいます.

実行は

roslaunch motoman_gazebo motoman_nishida_lab.launch
roslaunch motoman_moveit sia5_moveit_planning_execution.launch 

です.

ここがとても疑問で,先日紹介してくださった「Learning ROS for Robotics Programming - Second Edition」での練習ロボットでの実行例(p.387)の

roslaunch rosbook_arm_gazebo rosbook_arm_empty_world.launch
roslaunch rosbook_arm_moveit_config moveit_RViz.launch config:=true

では起きていない現象です.しっかり2回目以降のプランニングも現在の姿勢からの計画になっています. ここの問題をまず解決しなければ.と思っているのですが,できておりません.

本来なら私の方で検証を行っていくべきなのですが,もしよろしければお知恵を貸していただけませんでしょうか.

MoriKen254 commented 8 years ago

@Ry0 是非一緒に考えましょう^^

説明有り難うございます。流れは理解しました。

Rvizでも初期位置に戻るのは気になりますね。ただ、Rviz上でPlanningしたときのプレビューを見てもいい感じに見えるので、plan()部分がうまくいっているのに、go()でおかしなことになっているように見えます。あくまで推定段階です。

とりあえず、原因の切り分けのために、以下のことを整理しても良いですか?

実機での動作

下記リンクを見ると、実機の場合はうまく行っているように見えます。 https://www.youtube.com/watch?v=WvK1FSl2GSg&feature=youtu.be

今回の現象は、Gazeboを導入したことによって生じた問題でしょうか?

もし、実機の場合には生じない問題であれば、Gazebo、またはros_controlの設定に問題があると考えられます。 Learning ROS for Robotics Programming - Second Edition の6軸ロボットのURDFyamlと、motoman_projectのsia5のそれらを比較して、原因になりそうな箇所がないか探してみる価値はありそうです。

もし、実機でも生じるのであれば、Moveit!側の設定の問題を否定できなくなるので、もう少し切り分けが必要そうです。

Gazeboでの実績

過去に一度でもGazeboMoveit!の連携で、正常動作を確認したことはありますか? もし一度でもあるなら、その時以降の変更点による影響が考えられます。

Python API を使用することによる影響

この現象は、Pythonコードを実行した後に起こる現象でしょうか? つまり、起動してPythonコードは使わず、一発目からRvizでExecuteすれば発生しない、ということはないでしょうか? 当方で、ターミナルを再起動したてでRvizからPlan & Executeをしても一度初期姿勢に戻る挙動を示したので、この線はあまり期待はできないかもしれません。

ちなみに、Python APIを使ったコードを使って実機の動作を試みた場合でも、同じ現象が起こらず正常に動作するでしょうか?(怖いかもしれませんが) Pythonを使っても実機でうまく動いてくれるなら、Python コードが悪さをしている可能性は消せます。もし、Pythonを使ったことが誤動作のきっかけになるなら、そちらのコードのお作法の確認デバッグになります(コアダンプを直してみる)。

ひとまず現状の情報から考えられる可能性を挙げました。思いつきでつらつら書いているのでごちゃごちゃしてすみません。

意見あれば、お願いします。

Ry0 commented 8 years ago

@mum254 問題解決へのアプローチありがとうございます.

まず実機での動作についてですが,「Plan and Execute」のボタンをクリックでのプランニングはうまくできております.
ただしLearning ROS for Robotics Programming - Second Editionで提示されているロボットや,他の動画で登場しているモデル,人伝いで聞いた話から私たちだけの問題ではないのはわかっているのですが,Moveitプラグインのみの使用かつ,2回目以降のプランニングにおいて「Plan」ボタンと「Execute」ボタンを別々でクリックすると初期位置からのプランニング結果になってしまいます.(この場合,実機は現在姿勢から初期姿勢に戻るような指令が出るのでエラーとなって,Gazeboの場合は急激な入力が入って振動します.) このバグ??も今回の原因と何か関係があるかもと思って記録しておきます.

Gazeboでの実績については, @RyodoTanaka がGazeboのシミュレータを構築してくれた当初から起きていることがわかっています.

Python APIを使用することに影響については,最近になってPythonを使ってMoveitの基本的なAPIを理解しようと思いはじめました.Rviz上でのMoveitプラグインで遊ぶだけっていうのは終わりにしたかったので.

ですのでPython APIを使う以前から,「初期姿勢からのプランニングになっちゃう問題」は起きています.

あと実機での動作については未検証です.結果が分かり次第ここに書き込むように致します.

いろいろ書いてぐちゃぐちゃですが,どうぞよろしくお願いします.

MoriKen254 commented 8 years ago

@Ry0 ありがとうございます。だんだん見えてきました。

実機での動作については、確認をお願いします。 以下、Gazeboでのシミュレーションについて述べます。

こちらで確認した動作と、頂いた情報から、

に切り分けられないかな、と考えています。

ひとまず、以下のような理解でよろしいでしょうか。

モデルに依存しない問題

これはMoveit!の仕様のように思われました。Learning ROS for Robotics Programmingrosbook_armのモデルで本現象を確認しましたが、こちらの環境では下記の方法で回避できました。

実際のコードで目標位置を切り替えてplanとgoをするときでも、目標を切り替える毎に明示的にStart Stateをcurrent にしたほうが良いかもしれません。自分で確かめるべきところですが、今コーディングの方に手が出ないので、取り急ぎAPIリファレンスにあった怪しそうなメソッドを参考に貼っておきます。

motoman で発生する問題

これがやっかい極まりないです。 少なくともこちらの環境では、前述したQuerySelect Start State<current>Updateでも解決できません。Start Stateが更新されていないことが原因と考えます。以下に理由を述べます。

これに対しては、なぜStart Stateが更新されないのか、コレを更新するためには何をすればいいのかを調査することになります。

すみません、とりあえずここまで。

RyodoTanaka commented 8 years ago

@mum254 @Ry0 検討ありがとうございます。 https://groups.google.com/forum/#!topic/moveit-users/QDYSI5hq5L4 こちらのissueが全く同じ状況であったので読み進めていたのですが、 move_groupによってsceneが生成されていないと起こる現象のようです。 実際、motomanでmove_groupをlaunchすると、

[ WARN] [1454474146.814158869, 1651.708000000]: Failed to call service /get_planning_scene, have you launched move_group? at /tmp/buildd/ros-indigo-moveit-ros-planning-0.6.5-0trusty-20151201-0131/planning_scene_monitor/src/planning_scene_monitor.cpp:461

という、警告メッセージが出ます。 これは、うまく動いているrosbookのロボットでは起きません。 なので、おそらくこれが原因だと思うのですが、解決策は今のところ見つかっていません。 また追記します。

RyodoTanaka commented 8 years ago

@mum254 @Ry0 fix_moveitブランチにて、上記のエラーが解決しました。 やったことと考察を述べます。

やったこと

  1. move_groupノードの呼び出しの際に、move_group/MoveGroupGetPlanningSceneServiceを呼び出していなかったので、これを追加しました。
  2. move_groupノードは通常/join_statesトピックをsubscribeしていますが、作成したGazeboモデルでは/sia5/joint_statesに情報をpublishしているため、reparamを用いてこれを変更しました。

考察

1.について、move_group/MoveGroupGetPlanningSceneServiceを追加することで、

[ WARN] [1454474146.814158869, 1651.708000000]: Failed to call service /get_planning_scene, have you launched move_group? at /tmp/buildd/ros-indigo-moveit-ros-planning-0.6.5-0trusty-20151201-0131/planning_scene_monitor/src/planning_scene_monitor.cpp:461

上記のエラーは消えて解決しました。 このプラグインはデフォルトで存在するものですが、私がファイルを編集中に誤って削除してしまっていたために起きたものと思われます。申し訳ありません。

2.について、変更を行ったところ、Gazebo上のモデルはrosbookのモデルと同じ挙動になりましたが、Rviz上のRobot_Sceneは更新されませんでした。 まず、Gazeboモデルと実機モデルに差があった理由ですが、Gazeboモデルでは、/sia5/joint_statesをpublishしており、実機では/joint_statesがpublishされていたため、実機の際にはrosbookと同じ動きをしており、Gazeboが失敗していた原因であると考えられます。 次に、Rvizの表示が更新されない理由ですが、これは現在のところはっきりした理由がわかりません。 追って検証したいと思います。

現状と課題のまとめ

現状

課題

MoriKen254 commented 8 years ago

@RyodoTanaka ありがとうございます.

  1. は肝でしたね.Start Stateが更新されなかった現象と,整合性がありそうです. Rviz上のScene については,もう少し調べる必要がありそうですね.

こちらでの動作確認等は,明日行います.

Pythonを使ったコードで、望みの挙動を得ることができるようになった。

これについて,もう少し教えていただけますか?何が望みで,得ることが出来なかったのはどの部分か.

Rviz上のRbot Sceneが、実際のロボットの姿勢と同期されない。 これにより、Plan -> Execute の手順で行うプランニングでは、currentの姿勢が更新されていないので、 ロボットへの指令値がこれまでと同じようにおかしくなってしまう。

Rviz上のMoveitプラグインの所で,Query→Select Start State→current→Update を押してからPlan -> Execute をしても,current の姿勢が更新された起動が生成されませんか?前回の私の投稿に記載したとおり,rosbook_armでは,この方法でcurrentの姿勢が更新されます.

RyodoTanaka commented 8 years ago

@mum254 1.については、ご迷惑をおかけしました。本当に申し訳ありません。

Pythonコードでの動作について

ここで挙げていた望みの挙動とは、

  1. Gazeboモデルの立ち上げ
  2. move_groupの立ち上げ
  3. Pythonのコードからゴール姿勢を与え、それにしたがってGazeboモデルが動作する ただし、連続して指令を与えても、現在姿勢から初期姿勢に戻るような指令が出るのでエラーとなって,Gazeboの場合は急激な入力が入って振動するという現象なく、プランニングの実行が行われることを指す

のことを指します。

続いて、

Rviz上のMoveitプラグインの所で,Query→Select Start State→→Update を押してからPlan -> Execute をしても,current の姿勢が更新された起動が生成されませんか?前回の私の投稿に記載したとおり,rosbook_armでは,この方法でcurrentの姿勢が更新されます.

上記についてですが、教えていただいた手順通りに行っても、currentの姿勢が更新されませんでした。 これの原因はまだわかっておりません。

さらなる問題

上記の通り、Pythonコードによる動作を行うことができたので、実機で試そうとしたところ、うまく行きませんでした。これについては、原因を切り分けることが現時点ではできていません。。。 一つだけ考えられる原因は、Gazeboモデルでは、sia5という名前空間を追加しているのですが、実機には無いという点です。 Rvizの問題についてもこれが原因のように感じているので、一度sia5の名前空間を無くすよう検討中です。

まとまってなくて申し訳ありません。 よろしくお願いします。

MoriKen254 commented 8 years ago

@RyodoTanaka ありがとうございます。理解しました。 Plan and Executeでは、うまく行くようですね。

Rviz でScene が同期されない問題

不思議ですね。前からこうでしたっけ? Hydro版ですが、気になるissueを載せときます。 https://github.com/ros-planning/moveit_ros/issues/405

Plan->Executeでうまく行かない問題

この件の本質的な問題は、currentの姿勢でStart Stateを更新出来ないことにあるように思われます。 こう思う理由を述べます。

下記のように操作をすれば、Plan->Executeの順で操作すると、急激な動きなしで動作します。

  1. インタラクティブマーカを、前回ナビゲーションしたゴール位置から現在姿勢をずらさない状態で、Query→Select Start State→same as goal→Update (これで、次回のスタートと前回のゴール[すなわち現在姿勢]が重なる)
  2. インタラクティブマーカでさきっちょを動かしてPlan->Executeを順番に実行

一方、下記のように操作してもうまくいきません。

  1. インタラクティブマーカを、前回ナビゲーションしたゴール位置からずらさない状態で、Query→Select Start State→current→Update (これで、次回のスタートと現在姿勢[すなわち前回のゴール]が重なることが期待されるが)
  2. インタラクティブマーカでさきっちょを動かしてPlan->Executeを順番に実行

上記2つの操作の違いはただ一点、状態選択時のsame as goalcurrentかのみです。前者ではゴールの状態を取得してスタートに設定できているので、後者ではcurrentの状態を取得できていないことが推察できる現象です。

確かに、名前空間の問題が絡んでいる可能性はあります。

Rvizのプラグイン側が、名前空間なしのjoint_statesを読んでいるかもしれないと思い、下記コマンドでトピックを複製してみましたが、現象は変わりませんでした。

rosrun topic_tools relay sia5/joint_states joint_states

一旦名前空間をなくしたモデルで同じことを試して、原因を切り分けてみるのは賛成です。

Pythonで2つ目以降の目標でうまくいかない問題

やはり、StartStateの問題と推測します。 1つめのplan, goの後に、Start State を更新する必要があると考えます。以前の私の投稿で書いた、 Python: set_start_state_to_current_state() CPP: setStartStateToCurrentState() は、前述した`Plan->Executeでうまく行かない問題`が解決しないと機能しそうにありません。

ということで、 Python: set_start_state() CPP: setStartState()

を使って、現在の状態を、明示的に更新するのはいかがでしょうか。より具体的には、1つ目のgoが終わった後、1つ目の経路計画のゴール位置で、Start Stateを更新します。 使い方としては、cppのサンプルは下記サイトにあります。 http://docs.ros.org/hydro/api/pr2_moveit_tutorials/html/planning/src/doc/move_group_interface_tutorial.html#planning-with-path-constraints

python側を見つけられていないのですが、本質的には同じはずです。

情報諸々

以上、よろしくお願いします。

MoriKen254 commented 8 years ago

取り急ぎ、突貫生成物投下。rosook_armにて、cppで下記コードのノードを実行すると、急激に動くことなく、複数目標点を推移することを確認。 rosbook_arm_snippets move_group_plan_single_target.cppを適当に編集しただけ。整理も何もしていない。

#include <moveit/move_group_interface/move_group.h>

#include <moveit_msgs/DisplayTrajectory.h>

int main(int argc, char **argv)
{
    // Initialize ROS, create the node handle and an async spinner
    ros::init(argc, argv, "move_group_plan_single_target");
    ros::NodeHandle nh;

    ros::AsyncSpinner spin(1);
    spin.start();

    // Get the arm planning group
    moveit::planning_interface::MoveGroup plan_group("arm");

    // Create a published for the arm plan visualization
    ros::Publisher display_pub = nh.advertise<moveit_msgs::DisplayTrajectory>("/move_group/display_planned_path", 1, true);

    // Set a goal message as a pose of the end effector
    geometry_msgs::Pose goal;
    goal.orientation.x = -0.000764819;
    goal.orientation.y = 0.0366097;
    goal.orientation.z = 0.00918912;
    goal.orientation.w = 0.999287;
    goal.position.x = 0.775884;
    goal.position.y = 0.43172;
    goal.position.z = 2.71809;

    // Set the tolerance to consider the goal achieved
    plan_group.setGoalTolerance(0.2);

    // Set the target pose, which is the goal we already defined
    plan_group.setPoseTarget(goal);

    // Perform the planning step, and if it succeeds display the current
    // arm trajectory and move the arm
    moveit::planning_interface::MoveGroup::Plan goal_plan;
    if (plan_group.plan(goal_plan))
    {
        moveit_msgs::DisplayTrajectory display_msg;
        display_msg.trajectory_start = goal_plan.start_state_;
        display_msg.trajectory.push_back(goal_plan.trajectory_);
        display_pub.publish(display_msg);

        sleep(5.0);

        plan_group.move();
    }

    sleep(7.0);

    goal.orientation.x = -0.000764819+0.01;
    goal.orientation.y = 0.0366097-0.01;
    goal.orientation.z = 0.00918912-0.01;
    goal.orientation.w = 0.999287;
    goal.position.x = 0.775884;
    goal.position.y = 0.43172;
    goal.position.z = 2.71809;

    // Set the tolerance to consider the goal achieved
    plan_group.setGoalTolerance(0.2);

    // Set the target pose, which is the goal we already defined
    plan_group.setPoseTarget(goal);

    // Perform the planning step, and if it succeeds display the current
    // arm trajectory and move the arm
    moveit::planning_interface::MoveGroup::Plan goal_plan2;
    if (plan_group.plan(goal_plan2))
    {
        moveit_msgs::DisplayTrajectory display_msg;
        display_msg.trajectory_start = goal_plan2.start_state_;
        display_msg.trajectory.push_back(goal_plan2.trajectory_);
        display_pub.publish(display_msg);

        sleep(5.0);

        plan_group.move();
    } 
    ros::shutdown();

    return 0;
}
RyodoTanaka commented 8 years ago

@mum254 ありがとうございます。 問題点について、いくつか情報を共有しておきたいと思います。

Rviz でScene が同期されない問題

不思議ですね。前からこうでしたっけ? Hydro版ですが、気になるissueを載せときます。 https://github.com/ros-planning/moveit_ros/issues/405

この現象は以前からこのままでした。 しかし、貼り付けて頂いたissueなどを見て、moveit側の問題なのだと前々から考えておりました。 一方、rosbookの方はこの現象が起きないため、最近になって、こちら側の問題であることを認識した次第です。

Plan->Executeでうまく行かない問題

下記のように操作をすれば、Plan->Executeの順で操作すると、急激な動きなしで動作します。

  1. インタラクティブマーカを、前回ナビゲーションしたゴール位置から現在姿勢をずらさない状態で、Query→Select Start State→same as goal→Update (これで、次回のスタートと前回のゴール[すなわち現在姿勢]が重なる)
  2. インタラクティブマーカでさきっちょを動かしてPlan->Executeを順番に実行

一方、下記のように操作してもうまくいきません。

  1. インタラクティブマーカを、前回ナビゲーションしたゴール位置からずらさない状態で、Query→Select Start State→current→Update (これで、次回のスタートと現在姿勢[すなわち前回のゴール]が重なることが期待されるが)
  2. インタラクティブマーカでさきっちょを動かしてPlan->Executeを順番に実行

上記2つの操作の違いはただ一点、状態選択時のsame as goalcurrentかのみです。前者ではゴールの状態を取得してスタートに設定できているので、後者ではcurrentの状態を取得できていないことが推察できる現象です。

実は、上記と全く同じ方法でこれまでは動かしていました。 なので、currentが更新されないのが問題の本質であるというのは、おっしゃるとおりだと思います。

Rvizのプラグイン側が、名前空間なしのjoint_statesを読んでいるかもしれないと思い、下記コマンドでトピックを複製してみましたが、現象は変わりませんでした。

rosrun topic_tools relay sia5/joint_states joint_states

実機のpublishするトピック名を変更しても同じでしたので、scenejoint_statesトピックをsubscribeしていないものと考えております。 また、以前発生した、

[ WARN] [1454474146.814158869, 1651.708000000]: Failed to call service /get_planning_scene, have you launched move_group? at /tmp/buildd/ros-indigo-moveit-ros-planning-0.6.5-0trusty-20151201-0131/planning_scene_monitor/src/planning_scene_monitor.cpp:461

というエラーを見る限り、sceneはTopicではなく、/get_planning_sceneでやりとりしているService(クライアント?)であると考えられます。 ここまではわかるのですが、それからどうしたら良いのかよくわかりません。。。

Pythonで2つ目以降の目標でうまくいかない問題

やはり、StartStateの問題と推測します。 1つめのplan, goの後に、Start State を更新する必要があると考えます。以前の私の投稿で書いた、 Python: set_start_state_to_current_state() CPP: setStartStateToCurrentState() は、前述した`Plan->Executeでうまく行かない問題`が解決しないと機能しそうにありません。

ということで、 Python: set_start_state() CPP: setStartState()

を使って、現在の状態を、明示的に更新するのはいかがでしょうか。より具体的には、1つ目のgoが終わった後、1つ目の経路計画のゴール位置で、Start Stateを更新します。 使い方としては、cppのサンプルは下記サイトにあります。 http://docs.ros.org/hydro/api/pr2_moveit_tutorials/html/planning/src/doc/move_group_interface_tutorial.html#planning-with-path-constraints

上記の方法だと、StartStateの初期化をcurrentではなく、same as goalにした時と同じになると理解しました。 Rviz上でうまく行っているので、これならうまく行くと思います。 検証後、報告します。

以上、よろしくお願いします。

P.S. もしよろしければ、検証頂いたソースを独自のブランチに、pushしていただけると助かります。 今回の場合ですと、親:fix_moveit -> 子:hogehoge が良いと思われます。 お手数ですが、よろしくお願いします。

MoriKen254 commented 8 years ago

情報ありがとうございます!

ソースはちょっと時間下さい。あれ、ROS本側のソースなので、motoman用に書き換えが必要で。

RyodoTanaka commented 8 years ago

@mum254 本日、最新のfix_moveitブランチにて実装してみました。 と言っても、issueに貼り付けていただいたソースをそのまま貼り付けて、CMakeLists.txtとpackage.xmlをそれに沿うように編集しただけなのですが。。。 いずれにせよ、実機での実験はまだ行っていないので、明日お越しになる際にご覧いただけると幸いです。 よろしくお願いします。

RyodoTanaka commented 8 years ago

@mum254 先ほど、fix_moveitブランチに、Goal座標を修正したCPPソースコードを追加しました。 また、このソースによってGazeboモデルが動作する(2点連続でプランニング成功&動作)ことを確認しました。 実機はこれから試しますので、追って報告します。

RyodoTanaka commented 8 years ago

@mum254 @Ry0 先ほどのソースで実機も動きました!! ただし、move_group.launchremap部分をコメントアウトした状態です。 いずれにせよ、大きく進展しました!ありがとうございます!!!!!!!!!!!!

MoriKen254 commented 8 years ago

@RyodoTanaka おー!すばらしい!!検証ありがとうございます。コードから軌道を制御できるようになったのは、ひとまず前進ですね^^

あと、すみません、cppやCMakelistsの中で、モデルに依存する部分はありませんでしたね。issueを確認した時にパソコンを使えなくて、色々見落としていて勘違いしていました。失礼致しました^^;

CPPとPythonの違い

となると、今度はcppではできるのに、pythonで同じことしてうまく行かないのが不思議ですね。cpp側でplanをすれば、start state がちゃんと更新されるようになっているのですね。

pythonはcppと仕様が異なり、明示的にstart stateを更新しなければならない、ということなら、それに従うしかないかもしれません。rosbook_arm側でも

一応両者のコードを比較を書いておきます。大きくみて以下の点が異なるかな、と思います。

  1. 経路計画について
    • cpp: plan()メソッドで実行している
    • py: plan に相当するメソッドは実行されていない

plan+executeで一気にやるか、別々にやるかの違いだとは思いますが。前者はrviz上でプレビューをするためにわざわざplanを実行しているだけですね。

  1. ナビゲーション用メソッド
    • cpp: move()
    • py: go()

最初のとつながりますが。APIリファレンスを見ると、cpp側にgoはなく、py側にmoveはないのですね。 何にせよ、pyでも結局、goの中でmoveをしているので、やはり本質的にはcppとpyの差はないと思うのですが…

rosbook_arm での成功実績

下記のpythonコードをrosbook_armに対して実行したら、急激な動きをすることなく3つの目標に順番に動きました。fix_moveitに新規ファイルでダイレクトにpushしておきました。

#!/usr/bin/env python

import moveit_commander
import rospy
import geometry_msgs.msg
import copy

def main():
    rospy.init_node("moveit_command_sender")

    robot = moveit_commander.RobotCommander()

    print "=" * 10, " Robot Groups:"
    print robot.get_group_names()

    print "=" * 10, " Printing robot state"
    print robot.get_current_state()
    print "=" * 10

    arm = moveit_commander.MoveGroupCommander("arm")

    print "=" * 15, " Arm ", "=" * 15
    print "=" * 10, " Reference frame: %s" % arm.get_planning_frame()

    print "=" * 10, " Reference frame: %s" % arm.get_end_effector_link()

    arm_initial_pose = arm.get_current_pose().pose
    print "=" * 10, " Printing initial pose: "
    print arm_initial_pose

    target_pose = geometry_msgs.msg.Pose()

    target_pose.position.x = 0.5
    target_pose.position.y = -0.25
    target_pose.position.z = 2.5
    target_pose.orientation.x = 0.0
    target_pose.orientation.y = 0.0
    target_pose.orientation.z = 0.0
    target_pose.orientation.w = 1.0
    arm.set_pose_target(target_pose)

    print "=" * 10, " plan1..."
    arm.go()
    rospy.sleep(2)

    print "=" * 10, " Planning to a joint-space goal"
    arm.clear_pose_targets()
    print "=" * 10, " Joint values: ", arm.get_current_joint_values()

    target_pose.position.x = 0.4
    target_pose.position.y = -0.15
    target_pose.position.z = 2.4
    target_pose.orientation.x = 0.0
    target_pose.orientation.y = 0.0
    target_pose.orientation.z = 0.0
    target_pose.orientation.w = 1.0
    arm.set_pose_target(target_pose)

    print "=" * 10, " plan2..."
    arm.go()
    rospy.sleep(2)

    print "=" * 10, " Planning to a joint-space goal"
    arm.clear_pose_targets()
    print "=" * 10, " Joint values: ", arm.get_current_joint_values()

    target_pose.position.x = 0.4
    target_pose.position.y = -0.15
    target_pose.position.z = 2.7
    target_pose.orientation.x = 0.0
    target_pose.orientation.y = 0.0
    target_pose.orientation.z = 0.0
    target_pose.orientation.w = 1.0
    arm.set_pose_target(target_pose)

    print "=" * 10, " plan3..."
    arm.go()
    rospy.sleep(2)

if __name__ == '__main__':
    try:
        main()
    except rospy.ROSInterruptException:
        pass
RyodoTanaka commented 8 years ago

@mum254 @Ry0

currentの更新もうまく行くようになったので、閉じます