Closed MoriKen254 closed 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上で動きを見せてくれます.
ですが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回目以降のプランニングも現在の姿勢からの計画になっています. ここの問題をまず解決しなければ.と思っているのですが,できておりません.
本来なら私の方で検証を行っていくべきなのですが,もしよろしければお知恵を貸していただけませんでしょうか.
@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軸ロボットのURDF
やyaml
と、motoman_project
のsia5のそれらを比較して、原因になりそうな箇所がないか探してみる価値はありそうです。
もし、実機でも生じるのであれば、Moveit!
側の設定の問題を否定できなくなるので、もう少し切り分けが必要そうです。
Gazebo
での実績過去に一度でもGazebo
とMoveit!
の連携で、正常動作を確認したことはありますか?
もし一度でもあるなら、その時以降の変更点による影響が考えられます。
この現象は、Pythonコードを実行した後に起こる現象でしょうか?
つまり、起動してPythonコードは使わず、一発目からRviz
でExecuteすれば発生しない、ということはないでしょうか?
当方で、ターミナルを再起動したてでRviz
からPlan & Executeをしても一度初期姿勢に戻る挙動を示したので、この線はあまり期待はできないかもしれません。
ちなみに、Python APIを使ったコードを使って実機の動作を試みた場合でも、同じ現象が起こらず正常に動作するでしょうか?(怖いかもしれませんが) Pythonを使っても実機でうまく動いてくれるなら、Python コードが悪さをしている可能性は消せます。もし、Pythonを使ったことが誤動作のきっかけになるなら、そちらのコードのお作法の確認デバッグになります(コアダンプを直してみる)。
ひとまず現状の情報から考えられる可能性を挙げました。思いつきでつらつら書いているのでごちゃごちゃしてすみません。
意見あれば、お願いします。
@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を使う以前から,「初期姿勢からのプランニングになっちゃう問題」は起きています.
あと実機での動作については未検証です.結果が分かり次第ここに書き込むように致します.
いろいろ書いてぐちゃぐちゃですが,どうぞよろしくお願いします.
@Ry0 ありがとうございます。だんだん見えてきました。
実機での動作については、確認をお願いします。
以下、Gazebo
でのシミュレーションについて述べます。
こちらで確認した動作と、頂いた情報から、
に切り分けられないかな、と考えています。
ひとまず、以下のような理解でよろしいでしょうか。
Plan
ボタンと Execute
ボタンを別々にクリックして実行すると、モデルにかかわらず初期姿勢に戻ってからナビゲーションされてしまう。Plan and Execute
ボタンで実行した場合には発生しない。これはMoveit!の仕様のように思われました。Learning ROS for Robotics Programmingrosbook_arm
のモデルで本現象を確認しましたが、こちらの環境では下記の方法で回避できました。
Query
→Select Start State
→<current>
→Update
を押してからPlan
→Execute
を実行すれば、初期位置に戻る挙動は改善されます。Moviet!
の仕様では、Start State
からGoal State
の間の起動計画を立てるようですね。Start State
を明示的に変えているかどうかが、鍵のようです。Plan and Execute
を押した場合はStart State
の更新までかけてくる仕様のようです。Start State
をそのままに、色々目標位置を変えながらPlan
だけ見たいという要求がありそうなことが挙げられます。わかる気がします。実際のコードで目標位置を切り替えてplanとgoをするときでも、目標を切り替える毎に明示的にStart State
をcurrent にしたほうが良いかもしれません。自分で確かめるべきところですが、今コーディングの方に手が出ないので、取り急ぎAPIリファレンスにあった怪しそうなメソッドを参考に貼っておきます。
Plan
ボタンと Execute
ボタンを別々にクリックして実行しようが、Plan and Execute
をクリックして実行しようが、初期姿勢に戻ってからナビゲーションされてしまう。これがやっかい極まりないです。
少なくともこちらの環境では、前述したQuery
→Select Start State
→<current>
→Update
でも解決できません。Start State
が更新されていないことが原因と考えます。以下に理由を述べます。
Query
→Select Start State
→<current>
→Update
をしたあとに、Query
→Select Goal State
→<same as start>
→Update
をクリックしたとき
の挙動が、rosbook_arm
とmotoman
で異なります。rosbook_arm
の場合(期待通りに動作)
Start State
が更新されるはずです。ii を実行すれば、i で設定した位置がGoal State
になることが期待されます。つまり、始点と終点が重なります。rosbook_arm
ではこの通りに動きます。 motoman
の場合
rosbook_arm
と同一の操作をしても、必ず初期位置に戻ってしまいます。つまり、Start State
が全く更新されていません。Plan
ボタンと Execute
ボタンを別々にクリックして実行しようが、Plan and Execute
をクリックして実行しようが、この更新されていないStart State
に戻ろうとするから、このような挙動を示すのだと考えられます。これに対しては、なぜStart State
が更新されないのか、コレを更新するためには何をすればいいのかを調査することになります。
すみません、とりあえずここまで。
@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のロボットでは起きません。 なので、おそらくこれが原因だと思うのですが、解決策は今のところ見つかっていません。 また追記します。
@mum254
@Ry0
fix_moveit
ブランチにて、上記のエラーが解決しました。
やったことと考察を述べます。
move_group/MoveGroupGetPlanningSceneService
を呼び出していなかったので、これを追加しました。/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の表示が更新されない理由ですが、これは現在のところはっきりした理由がわかりません。
追って検証したいと思います。
Rbot Scene
が、実際のロボットの姿勢と同期されない。
これにより、Plan -> Execute の手順で行うプランニングでは、current
の姿勢が更新されていないので、
ロボットへの指令値がこれまでと同じようにおかしくなってしまう。Robot Scene
の情報を、同期する必要がある@RyodoTanaka ありがとうございます.
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の姿勢が更新されます.
@mum254 1.については、ご迷惑をおかけしました。本当に申し訳ありません。
ここで挙げていた望みの挙動とは、
のことを指します。
続いて、
Rviz上のMoveitプラグインの所で,Query→Select Start State→→Update を押してからPlan -> Execute をしても,current の姿勢が更新された起動が生成されませんか?前回の私の投稿に記載したとおり,rosbook_armでは,この方法でcurrentの姿勢が更新されます.
上記についてですが、教えていただいた手順通りに行っても、currentの姿勢が更新されませんでした。 これの原因はまだわかっておりません。
上記の通り、Pythonコードによる動作を行うことができたので、実機で試そうとしたところ、うまく行きませんでした。これについては、原因を切り分けることが現時点ではできていません。。。
一つだけ考えられる原因は、Gazeboモデルでは、sia5
という名前空間を追加しているのですが、実機には無いという点です。
Rvizの問題についてもこれが原因のように感じているので、一度sia5
の名前空間を無くすよう検討中です。
まとまってなくて申し訳ありません。 よろしくお願いします。
@RyodoTanaka
ありがとうございます。理解しました。
Plan and Execute
では、うまく行くようですね。
不思議ですね。前からこうでしたっけ? Hydro版ですが、気になるissueを載せときます。 https://github.com/ros-planning/moveit_ros/issues/405
Plan
->Execute
でうまく行かない問題この件の本質的な問題は、currentの姿勢でStart State
を更新出来ないことにあるように思われます。
こう思う理由を述べます。
下記のように操作をすれば、Plan
->Execute
の順で操作すると、急激な動きなしで動作します。
same as goal
→Update (これで、次回のスタートと前回のゴール[すなわち現在姿勢]が重なる)Plan
->Execute
を順番に実行一方、下記のように操作してもうまくいきません。
current
→Update (これで、次回のスタートと現在姿勢[すなわち前回のゴール]が重なることが期待されるが)Plan
->Execute
を順番に実行上記2つの操作の違いはただ一点、状態選択時のsame as goal
かcurrent
かのみです。前者ではゴールの状態を取得してスタートに設定できているので、後者ではcurrentの状態を取得できていないことが推察できる現象です。
確かに、名前空間の問題が絡んでいる可能性はあります。
Rvizのプラグイン側が、名前空間なしのjoint_states
を読んでいるかもしれないと思い、下記コマンドでトピックを複製してみましたが、現象は変わりませんでした。
rosrun topic_tools relay sia5/joint_states joint_states
一旦名前空間をなくしたモデルで同じことを試して、原因を切り分けてみるのは賛成です。
やはり、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側を見つけられていないのですが、本質的には同じはずです。
以上、よろしくお願いします。
取り急ぎ、突貫生成物投下。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;
}
@mum254 ありがとうございます。 問題点について、いくつか情報を共有しておきたいと思います。
不思議ですね。前からこうでしたっけ? Hydro版ですが、気になるissueを載せときます。 https://github.com/ros-planning/moveit_ros/issues/405
この現象は以前からこのままでした。 しかし、貼り付けて頂いたissueなどを見て、moveit側の問題なのだと前々から考えておりました。 一方、rosbookの方はこの現象が起きないため、最近になって、こちら側の問題であることを認識した次第です。
Plan
->Execute
でうまく行かない問題下記のように操作をすれば、
Plan
->Execute
の順で操作すると、急激な動きなしで動作します。
- インタラクティブマーカを、前回ナビゲーションしたゴール位置から現在姿勢をずらさない状態で、Query→Select Start State→
same as goal
→Update (これで、次回のスタートと前回のゴール[すなわち現在姿勢]が重なる)- インタラクティブマーカでさきっちょを動かして
Plan
->Execute
を順番に実行一方、下記のように操作してもうまくいきません。
- インタラクティブマーカを、前回ナビゲーションしたゴール位置からずらさない状態で、Query→Select Start State→
current
→Update (これで、次回のスタートと現在姿勢[すなわち前回のゴール]が重なることが期待されるが)- インタラクティブマーカでさきっちょを動かして
Plan
->Execute
を順番に実行上記2つの操作の違いはただ一点、状態選択時の
same as goal
かcurrent
かのみです。前者ではゴールの状態を取得してスタートに設定できているので、後者ではcurrentの状態を取得できていないことが推察できる現象です。
実は、上記と全く同じ方法でこれまでは動かしていました。
なので、current
が更新されないのが問題の本質であるというのは、おっしゃるとおりだと思います。
Rvizのプラグイン側が、名前空間なしの
joint_states
を読んでいるかもしれないと思い、下記コマンドでトピックを複製してみましたが、現象は変わりませんでした。rosrun topic_tools relay sia5/joint_states joint_states
実機のpublishするトピック名を変更しても同じでしたので、scene
はjoint_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(クライアント?)であると考えられます。
ここまではわかるのですが、それからどうしたら良いのかよくわかりません。。。
やはり、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
が良いと思われます。
お手数ですが、よろしくお願いします。
情報ありがとうございます!
ソースはちょっと時間下さい。あれ、ROS本側のソースなので、motoman用に書き換えが必要で。
@mum254
本日、最新のfix_moveit
ブランチにて実装してみました。
と言っても、issueに貼り付けていただいたソースをそのまま貼り付けて、CMakeLists.txtとpackage.xmlをそれに沿うように編集しただけなのですが。。。
いずれにせよ、実機での実験はまだ行っていないので、明日お越しになる際にご覧いただけると幸いです。
よろしくお願いします。
@mum254
先ほど、fix_moveit
ブランチに、Goal座標を修正したCPPソースコードを追加しました。
また、このソースによってGazeboモデルが動作する(2点連続でプランニング成功&動作)ことを確認しました。
実機はこれから試しますので、追って報告します。
@mum254
@Ry0
先ほどのソースで実機も動きました!!
ただし、move_group.launch
のremap
部分をコメントアウトした状態です。
いずれにせよ、大きく進展しました!ありがとうございます!!!!!!!!!!!!
@RyodoTanaka おー!すばらしい!!検証ありがとうございます。コードから軌道を制御できるようになったのは、ひとまず前進ですね^^
あと、すみません、cppやCMakelistsの中で、モデルに依存する部分はありませんでしたね。issueを確認した時にパソコンを使えなくて、色々見落としていて勘違いしていました。失礼致しました^^;
となると、今度はcppではできるのに、pythonで同じことしてうまく行かないのが不思議ですね。cpp側でplanをすれば、start state がちゃんと更新されるようになっているのですね。
pythonはcppと仕様が異なり、明示的にstart stateを更新しなければならない、ということなら、それに従うしかないかもしれません。rosbook_arm側でも
一応両者のコードを比較を書いておきます。大きくみて以下の点が異なるかな、と思います。
plan()
メソッドで実行しているplan+executeで一気にやるか、別々にやるかの違いだとは思いますが。前者はrviz上でプレビューをするためにわざわざplanを実行しているだけですね。
move()
go()
最初のとつながりますが。APIリファレンスを見ると、cpp側にgo
はなく、py側にmove
はないのですね。
何にせよ、pyでも結局、go
の中でmove
をしているので、やはり本質的にはcppとpyの差はないと思うのですが…
下記の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
@mum254 @Ry0
currentの更新もうまく行くようになったので、閉じます
python でmoveit API を使って動かそうとしたら、うまく行かない?的な話があったと思います。初回はうまく行くけど、二点目で不自然な挙動を示す、的な。原因を突き止めたいですね。
コードはこれでしょうか? https://github.com/Nishida-Lab/motoman_project/blob/master/motoman_moveit/scripts/moveit_command_sender.py
この現象を再現するまでの手順と、現象に関する具体的な説明をいただけますか?