ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
1

move_arm: occasional problems with trajectory filter

asked 2011-07-08 06:55:52 -0500

Jonathan Realmuto gravatar image

updated 2011-07-10 23:09:39 -0500

Hello,

I am currently working on using move_arm (and associated packages) with our 7 dof manipulator. I am using diamondback. I used pr2_arm_navigation as a template and have generated all the appropriate config/launch files. The problem is when send a move_arm_joint_goal often I get an error from the trajectory_filter_server:

ERROR: Joint name r_base_RollJoint not found in raw joint state message

ERROR: Filter chain failed to process trajectory

ERROR: Service call to filter trajectory failed.

This happens quite often, about half the time, but when it doesn't happen the goal is reached. I am not sure why trajectory_filter_server is not finding this joint in the raw joint state message only sometimes. Any advice is greatly appreciated.

Other information:

trajectory_filter_server launch:

<launch> 
    <node pkg="trajectory_filter_server" name="trajectory_filter" type="trajectory_filter_server" output="screen">

        <rosparam command="load" file="$(find TRACBot_arm_navigation)/config/joint_limits.yaml"/>
        <rosparam command="load" file="$(find TRACBot_arm_navigation)/config/filters.yaml"/>

    <remap from="robot_description" to="robot_description" />
    <remap from="collision_map" to="collision_map_occ" />
    <remap from="collision_map_update" to="collision_map_occ_update" />    
    <param name="refresh_interval_collision_map" type="double" value="5.0" />
    <param name="refresh_interval_kinematic_state" type="double" value="1.0" />
    <param name="bounding_planes" type="string" value="0 0 1 -0.01" />
    <param name="compute_contacts" type="bool" value="false" />

    <param name="pointcloud_padd" type="double" value="0.00" />

    <rosparam command="load" file="$(find TRACBot_arm_navigation)/config/robot_padding.yaml" />     

    </node>
</launch>

filter config file:

service_type: FilterJointTrajectoryWithConstraints    
filter_chain:   
   -     
       name: unnormalize_trajectory  
       type: UnNormalizeFilterJointTrajectoryWithConstraints           
   -    
      name: cubic_spline_short_cutter_smoother  
      type: CubicSplineShortCutterFilterJointTrajectoryWithConstraints      
      params: {discretization: 0.01}

Thanks,

Jonathan

edit retag flag offensive close merge delete

Comments

How are you publishing your joint states, i.e. how /joint_states topic is being populated?
arebgun gravatar image arebgun  ( 2011-07-08 07:10:32 -0500 )edit

2 Answers

Sort by » oldest newest most voted
0

answered 2011-07-19 04:08:21 -0500

Jonathan Realmuto gravatar image

Thank you Martin.

I figured out the problem. I was publishing two different joint state messages - one for my 7 dof manipulator and one for my pan/tilt camera mount. What was happening is about half the time the move_arm functions were receiving the correct 7 dof joint states and the other half the time received the 2 dof pan/tilt joint states. All joint states must be published in the same message.

The reason I used two different messages is that the pan/tilt mechanism was controlled using ptz-gazebo plugin and the 7 dof arm uses robot_mechanism_controller. I think the best thing to do is change the pt2-gazebo plugin to another robot_mechanism_controller.

edit flag offensive delete link more

Comments

I thought so. Still, I believe that this is not the best behaviour of trajectory_filter_server. It should be possible to send joint states from different nodes. Maybe @Sachin Chitta could comment on that? Or maybe we should file a ticket?
Martin Günther gravatar image Martin Günther  ( 2011-07-19 23:08:26 -0500 )edit
Martin Günther gravatar image Martin Günther  ( 2011-07-19 23:16:24 -0500 )edit
Thanks for the ticket, Martin. We will look into it.
Sachin Chitta gravatar image Sachin Chitta  ( 2011-07-20 16:35:30 -0500 )edit
0

answered 2011-07-10 23:11:51 -0500

updated 2011-07-10 23:13:16 -0500

You can get some debugging information by running rostopic echo /joint_states. Check that r_base_RollJoint is present in all the JointState messages, even if the joint did not move. Also, check that the joint states are published at a reasonable rate (say, at least 10 Hz or so). You can do that using rostopic hz /joint_states.

edit flag offensive delete link more

Question Tools

Stats

Asked: 2011-07-08 06:55:52 -0500

Seen: 410 times

Last updated: Jul 19 '11