Ask Your Question

Using object_manipulator on a non-PR2 robot

asked 2012-11-15 08:46:45 -0600

updated 2013-02-04 21:59:36 -0600

I'm trying to use the object_manipulator node on a non-PR2 robot, but it crashes when loading the PR2ArmKinematicsPlugin, which is unsurprising because I don't have a PR2 arm. This changeset suggests that one can exchange the PR2ArmKinematicsPlugin for a generic one, but I can't figure out how exactly. There doesn't seem to be a parameter to specify a different IK plugin.

It would be great if I could either

  • completely disable using the IK inside object_manipulator,
  • or even better, configure object_manipulator to use the arm_kinematics_constraint_aware plugin

At the moment, both options don't work because object_manipulator crashes on startup. Any hints?


Here's the complete backtrace. Summary: object_manipulator loads the PR2ArmKinematicsPlugin, which crashes because it expects a PR2 URDF and finds a Katana URDF. My URDF is fine, but I don't have some things like soft joint limits that the PR2 plugin expects to find.

gdb --args /home/martin/ros-fuerte/object_manipulator/bin/object_manipulator_node /GraspPlanning:=/openrave_grasp_planner arm/constraint_aware_ik:=/kurtana_arm_kinematics/get_constraint_aware_ik arm/get_fk:=/kurtana_arm_kinematics/get_fk arm/get_ik_solver_info:=/kurtana_arm_kinematics/get_ik_solver_info arm/interpolated_ik:=/interpolated_ik_motion_plan arm/interpolated_ik_set_params:=/interpolated_ik_motion_plan_set_params arm/get_state_validity:=/environment_server/get_state_validity arm/move_arm:=/move_arm arm/joint_trajectory:=/katana_arm_controller/joint_trajectory_action arm/hand_posture_execution:=/gripper_grasp_posture_controller arm/grasp_status:=/gripper_grasp_status __name:=object_manipulator

object_manipulator_node: /usr/include/boost/smart_ptr/shared_ptr.hpp:418: T* boost::shared_ptr<T>::operator->() const [with T = urdf::Joint]: Assertion `px != 0' failed.

Program received signal SIGABRT, Aborted.
0x00007ffff5e853a5 in __GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64  ../nptl/sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis nicht gefunden.
    in ../nptl/sysdeps/unix/sysv/linux/raise.c
(gdb) bt
#0  0x00007ffff5e853a5 in __GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007ffff5e88b0b in __GI_abort () at abort.c:92
#2  0x00007ffff5e7dd4d in __GI___assert_fail (assertion=0x7fffe431bc6b "px != 0", file=<optimized out>, line=418, function=<optimized out>) at assert.c:81
#3  0x00007fffe42fb92f in operator-> (this=<optimized out>) at /usr/include/boost/smart_ptr/shared_ptr.hpp:418
#4  operator-> (this=<optimized out>) at /tmp/buildd/ros-fuerte-pr2-kinematics-0.4.4/debian/ros-fuerte-pr2-kinematics/opt/ros/fuerte/stacks/pr2_kinematics/pr2_arm_kinematics/src/pr2_arm_ik.cpp:52
#5  pr2_arm_kinematics::PR2ArmIK::init (this=<optimized out>, robot_model=..., root_name="katana_base_link", tip_name="katana_motor5_wrist_roll_link")
    at /tmp/buildd/ros-fuerte-pr2-kinematics-0.4.4/debian/ros-fuerte-pr2-kinematics/opt/ros/fuerte/stacks/pr2_kinematics/pr2_arm_kinematics/src/pr2_arm_ik.cpp:62
#6  0x00007fffe4303c2c in pr2_arm_kinematics::PR2ArmIKSolver::PR2ArmIKSolver (this=<optimized out>, robot_model=..., root_frame_name="katana_base_link", tip_frame_name="katana_motor5_wrist_roll_link", 
    search_discretization_angle=<optimized out>, free_angle=@0x7fffe01d4d6c)
    at /tmp/buildd/ros-fuerte-pr2-kinematics-0.4.4/debian/ros-fuerte-pr2-kinematics/opt/ros/fuerte/stacks/pr2_kinematics/pr2_arm_kinematics/src/pr2_arm_ik_solver.cpp:47
#7  0x00007fffe4316c6a in pr2_arm_kinematics::PR2ArmKinematicsPlugin::initialize (this=0x7fffe01d4d40, group_name="arm", base_name=<optimized out>, tip_name=<optimized out>, 
    search_discretization=<optimized out>)
    at /tmp/buildd/ros-fuerte-pr2-kinematics-0.4.4/debian/ros-fuerte-pr2-kinematics/opt/ros/fuerte/stacks/pr2_kinematics/pr2_arm_kinematics/src/pr2_arm_kinematics_plugin.cpp:89
#8  0x00007ffff0cfa224 in arm_kinematics_constraint_aware::ArmKinematicsSolverConstraintAware::ArmKinematicsSolverConstraintAware (this=0x7fffe01ce870, solver=<optimized out>, cm=0x7ffff69cf7c0, group_name=
    "arm") at /tmp/buildd/ros-fuerte-arm-navigation-1.1.11/debian/ros-fuerte-arm-navigation/opt/ros/fuerte/stacks/arm_navigation/arm_kinematics_constraint_aware/src/arm_kinematics_solver_constraint_aware.cpp:71
#9  0x00007ffff3b65e02 in object_manipulator::GraspTesterFast::GraspTesterFast (this=0x7fffe00082a0, cm=<optimized out>, plugin_name="pr2_arm_kinematics/PR2ArmKinematicsPlugin")
    at /home/martin/ros-fuerte/object_manipulator/src ...
edit retag flag offensive close merge delete

2 Answers

Sort by » oldest newest most voted

answered 2012-11-18 18:51:58 -0600

Ugo gravatar image

We're using the object manipulation stack with our robots. If you want to have a look at how we did that it is available on Launchpad (still in development so it's quite hard to install it etc...).

Regarding changing the IK for object manipulator, you should have a look at the file manipulator.launch. The object_manipulator node is commented out as we're not using it anymore (we replaced it by a simpler node in sr_pick_and_place), but the syntax for calling the IK for our arm is there (all the remaps). The IK solver was generated using the arm_navigation wizard.

Hope this helps.

edit flag offensive delete link more


Thanks for your help, Ugo! Unfortunately this doesn't solve the problem, though. The object_manipulator node has changed since you last used it, so your commented-out stuff won't work any more (mine looks pretty similar).

Martin Günther gravatar image Martin Günther  ( 2012-11-19 02:47:39 -0600 )edit

Ho OK my bad. May be you should look at sr_pick_and_place in the stack I linked in my answer? You could use it as a base to replace the object_manipulator.

Ugo gravatar image Ugo  ( 2012-11-19 02:51:01 -0600 )edit

answered 2013-02-06 15:28:22 -0600

hsiao gravatar image

I patched object_manipulator in Fuerte trunk (0.6 branch) to make the plugin name a param. Please let me know if it doesn't meet your needs. (I'll release soon--Fuerte debs in shadow-fixed are all screwed up at the moment, waiting for that to be fixed.)

Sorry I didn't see your post until now--all ROS Answers emails were going straight to my spam folder. :P

edit flag offensive delete link more


@hsiao wow great, please let me know, I've got some other patches to submit for object_manipulator and the pipeline.

dbworth gravatar image dbworth  ( 2013-02-07 04:51:24 -0600 )edit

@martin-gunther Another side-effect I found is that the solver gets loaded with its default parameters. For the KDL solver that's 500 solver iterations, and 3 search iterations. This is too low for a 6 or 7 DOF robot and it quickly fails. That's another reason for setting the params via a YAML file.

dbworth gravatar image dbworth  ( 2013-02-07 05:24:55 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2012-11-15 08:46:45 -0600

Seen: 337 times

Last updated: Feb 06 '13