elsey's profile - activity

Hi,

I'm using diamondback and rviz has segmentation faults often whenever I kill another node.

Should I expect this whenever stopping a node that was publishing a topic that rviz is subscribed to?

E.g.: I run roscore in one terminal, openni_camera openni_node.launch, and rviz from another terminal. I can view the /camera/rgb/points topic in rviz fine. However, if I stop the openni_node.launch, rviz segfaults.

Is there anything I can do to change the rosrun / roslaunch settings to prevent this? It would be helpful to not have to restart rviz everytime I want to stop a node to debug something.

Thanks.

I'm trying the tutorial for move_arm motion planning: http://www.ros.org/wiki/move_arm/Tutorials/MoveArmPoseGoal

I would like to be able to change the speed of the arm motions. Instead of launching the move_arm node with:

<include file="$(find pr2_arm_navigation_actions)/launch/move_right_arm.launch"/>

I add the parameter "move_arm_frequency" as below:

  <node pkg="move_arm" type="move_arm_simple_action" output="screen" name="move_right_arm">    
    <remap from="arm_ik" to="pr2_right_arm_kinematics/get_constraint_aware_ik" />   
    <param name="group" type="string" value="right_arm" />
    <param name="controller_action_name" type="string" value="/r_arm_controller/follow_joint_trajectory" />
    <param name="move_arm_frequency" type="double" value="80" />    
  </node>

I run the tutorial example, unchanged: rosrun pr2_arm_navigation_tutorials move_arm_simple_pose_goal

However, when I change the value of "move_arm_frequency" to different values (say 1 vs. 80), I see no noticeable change in the executed action time, either slower or faster. (The default value in move_arm_simple_action.cpp is 50.) I always reset to the same joint pose, relaunched the move_arm node, and verified with "rosparam get" that the parameter has new values.

I'm pretty sure the parameter is getting updated, since a value of 0 results in a runtime error. It seems that it should affect the action completion time in the CONTROL state:

move_arm_action_feedback_.time_to_completion = ros::Duration(1.0/move_arm_frequency_);

Is there a way to change the speed of the arm motion for the move_arm example, either through this parameter or another one?

There is no guaranteed ordering in roslaunch. All programs should behave nicely to work.

I'm assuming your second program just calls a service? What probably happens is that the service call is done before the service is up. To fix that you should wait until a service becomes available in the other program and then go into the processing part.

I'm trying to launch nodes in one combined launch file.

If I launch nodes separately using the two files below, calls to the IK services work fine (i.e. call the second node's service ik_trajectory, which uses the first node's ik solver) :

ik_solver.launch:

<launch>  
  <include file="$(find pr2_arm_navigation_kinematics)/launch/pr2_ik_rarm_node.launch"/>  
</launch>

cartesian_ik_trajectory.launch:

<launch>  
  <node pkg="ik_trajectory" type="ik_trajectory" name="ik_trajectory"/>  
</launch>

The IK also works if I run the first launch file and use "rosrun ik_trajectory ik_trajectory" in place of the second launch file.

However, if I combine the two commands in one launch file, the service calls fail even though the input / starting arm state for IK is the same:

combined.launch:

<launch>  
   <include file="$(find pr2_arm_navigation_kinematics)/launch/pr2_ik_rarm_node.launch"/>   
   <node pkg="ik_trajectory" type="ik_trajectory" name="ik_trajectory"/>   
</launch>

The node in the second launch file was written by someone else, so I'm trying to look into those details. However, I don't understand why the behavior should be different. Is there an ordering or timing issue with the IK solver? I can even launch the separate launch files in reverse order without problem. It's only when I combine the commands in one launch file that the service fails.

Note that there's no failure when I actually run the launch files, only when I call the service provided by the second ik_trajectory node. I checked rosservice list to see that the same services are available in either case.

Thanks, Eric, for pointing out the thread on the drivers issue.

I upgraded drivers from NVIDIA 260.19.06 to NVIDIA 260.19.44, and that solved the issue.