jbarry's profile - activity

I do test the "do something" code separately of course. But if I leave the wrappers untested then the only way I find b

Writing tests in ros2 Hi, I have a large number of tests in ROS2 in Python I would like to write that are essentially 1

Writing tests in ros2 Hi, I have a large number of tests in ROS2 I would like to write that are essentially 1. Publish

Hi,

Is it possible to create a recursive message type in ROS2? E.g.: message Node.msg int64 id my_msgs/Node neighbors

This is currently causing compiler errors in ROS2 Humble for me but I was wondering if there was a flag or something I could use?

For more context, I'm working on writing a protobuf to ROS converter (which has generally been straightforward). However protobuf allows recursive messages and message loops (e.g. message A references message B which references message A). Figuring out a ROS equivalent to this if ROS doesn't allow recursive messages is going to be tricky!

Thanks! -Jenny

Ah thanks! I googled a bunch but didn't find that. I wonder if pointing out that that solution isn't good for message

Unfortunately this doesn't help in my case. I'm writing a tool to automatically convert protobuf messages to ROS messag

Unfortunately this doesn't help in my case. I'm writing a tool to automatically convert protobufs messages to ROS messa

Recursive message definition in ROS2 Hi, Is it possible to create a recursive message type in ROS2? E.g.: message Node

Hi,

I would like to be able to run a bash script using ros2 run <my package> <my shell script>. I have added the shell script (estop_nogui.sh) to the setup.py of the package (it's a Python package) as follows:

entry_points={
    'console_scripts': [
        'spot_ros2 = spot_driver.spot_ros2:main',
        'spot_commander = spot_driver.spot_commander:main',
        'estop_gui = spot_driver.estop_gui:main',
    ],
},
scripts = [
    'scripts/estop_nogui.sh',
],

This results in the file installed at install/spot_driver/lib/spot_driver/. It's an executable file but ros2 run can't find it. What else do I need to do for this?

Thanks!

-Jenny

Turns out I had two problems: 1) I had built in the wrong directory. Once I built in the correct directory ros2 run w

Turns out I had two problems: 1) I had built in the wrong directory. Once I built in the correct directory ros2 run wa

Turns out I had two problems: 1) I had built in the wrong directory. Once I built in the correct directory ros2 run wa

ros2 run bash script from Python package Hi, I would like to be able to run a bash script using ros2 run <my package

ros2 run bash script from Python package Hi, I would like to be able to run a bash script using ros2 run <my package

Running a shell script with ros2 run from a Python package Hi, I'd like to be able to do ros2 run <my package> &l

Hi,

I'm trying to write a unit test that tests converting between some messages types and one of the things I'd like to do is have a test that fails if the message's .msg file has changed at all (this is because it's important that the conversion functions be updated with the changed message and I want a reminder to do so). I'd be happy to just hard code the current message MD5 sum into my test, but how do I check the MD5 sum of the message to make sure it matches?

Thanks, Jenny

Hi,

I know that currently only Fuerte is support in Ubuntu 12.04. Will there ever be support for Electric and the older ROS distributions in 12.04 and beyond for people who want to run legacy code?

Thank you,

Jenny

Hi,

I would like to be able to run Gazebo remotely on a computer that is faster than my own computer. Pre-fuerte, this could be done by ssh'ing into the remote machine and running

roslaunch gazebo_worlds empty_world_no_x.launch

In fuerte, this crashes gazebo. I have tried using the -X flag with ssh and also setting export DISPLAY=:0 with no luck. I have also tried

roslaunch gazebo_worlds empty_world.launch gui:=false

and that also crashed trying to open a display with normal ssh. When ssh'd with -X, it crashes with the following error:

X Error of failed request:  GLXUnsupportedPrivateRequest
  Major opcode of failed request:  154 
  Minor opcode of failed request:  16 (X_GLXVendorPrivate)
  Serial number of failed request:  27
  Current serial number in output stream:  28

Is there a way to run Gazebo remotely in Fuerte?

Thanks,

Jenny

Hi,

I have found that if a node creates a planning_environment::CollisionModelsInterface object and also calls the /environment_server/set_planning_scene_diff service, the service always reports that it is unable to get a reply from planning scene client with the name of the node. Specifically, if I run the pr2_tabletop_manipulation_launch pr2_tabletop_manipulation.launch file and this piece of test code:

int main(int argc, char **argv) {
  ros::init(argc, argv, "planning_scene_test_node");
  ros::NodeHandle n;

  ros::ServiceClient scene_client =
    n.serviceClient<arm_navigation_msgs::setplanningscenediff>
    ("/environment_server/set_planning_scene_diff");
  ROS_INFO("Waiting for planning scene service");
  scene_client.waitForExistence();
  ROS_INFO("Planning scene service is now available");

  planning_environment::CollisionModelsInterface cmi("robot_description");
  arm_navigation_msgs::SetPlanningSceneDiff ssd;
  if (!scene_client.call(ssd)) {
    ROS_ERROR("Unable to set planning scene");
    return 1;
  }
  ROS_INFO("Successfully set planning scene");
  return 0;
}

[ INFO] [1322764074.606153612, 4535.143000000]: Successfully connected to planning scene action server for /planning_scene_test_node
[ INFO] [1322764080.585060399, 4540.165000000]: Did not get reply from planning scene client /planning_scene_test_node.  Incrementing counter to 1

The collision models interface declared within this node also does not update to the new planning scene and has to be set manually.

I am using 64-bit Ubuntu 10.04 and ROS electric. The version of the arm_navigation stack is 1.0.7-s1321929829~lucid.

Thanks,

Jenny

Hi,

I've been using the OMPL planner for the PR2 arm in fairly constrained situations (trying to pick items out of a cabinet) and it keeps returning invalid plans. Specifically, it returns a plan that hits an obstacle in the environment. Usually when this is the case it prints out a message that the "plan appears to have become invalidated already". When I check the validity of the plan using the planning_environment trajectory validity checker, it is indeed invalid. If I actually run the plan, the arm will collide with an obstacle. The environment is not dynamic; the obstacles the arm collides with were present and in the collision map during planning.

At the moment, I am simply re-planning when and invalid plan is returned and usually it will eventually find a valid plan, but I have had over 50 invalid plans returned. Each plan takes some computation time and then more time for the validity check, making for an unacceptably long planning time even when a valid plan is eventually found. The return from the planner is always 0 (whether the plan is valid or not). I tried using the pick and place pickup action for the same goal and observed the same behavior; the plans returned are usually invalid and the pickup action usually fails.

I give the planner 45 seconds, which it never uses all of and often some ordered collisions, but never the ones that invalidate the plan. I've reproduced the full call below.

Has anyone else seen this? Is there something simple I am overlooking?

Thanks, Jenny

motion_planning_msgs::GetMotionPlan mprsrv;

mprsrv.request.motion_plan_request.group_name =
    handDescription().armGroup(req.pickup_goal.arm_name);
mprsrv.request.motion_plan_request.num_planning_attempts = 1;
mprsrv.request.motion_plan_request.allowed_planning_time = 
    ros::Duration(45.0);

//I set mprsrv.request.motion_plan_request.goal_constraints, which is long and
//dependent on the arguments to the function so I've omitted it
mprsrv.request.motion_plan_request.ordered_collision_operations = 
    collisionOperationsForGrasp(req.pickup_goal, req.names);

//I set the starting state equal to the robot's current state using get_robot_state

mprsrv.request.motion_plan_request.workspace_parameters.
    workspace_region_pose.header.stamp = ros::Time::now();

ros::ServiceClient planner = 
   n.serviceClient<motion_planning_msgs::GetMotionPlan>
  ("/ompl_planning/plan_kinematic_path");

ROS_INFO("Waiting for planning service"); planner.waitForExistence(); ROS_INFO("Planning"); bool goodcall = planner.call(mprsrv); ROS_INFO("Finished planning");

Hi,

I'm seeing a segmentation fault running robot_self_filter_color in ROS Fuerte using the default installation of PCL, which I believe is PCL 1.5. I am using the following launch file to start the Kinect and filter out the PR2 using the self filter

  <launch>
  <arg name="kinect_frame_prefix" default="/head_mount_kinect" />
  <arg name="kinect_camera_name" default="head_mount_kinect" />
  <arg name="high_res" default="false" />

  <!-- separate self filter Kinect points for creating object models with higher resolution-->
  <node pkg="robot_self_filter_color" type="self_filter_color" respawn="true" name="object_modeling_kinect_self_filter" output="screen" launch-prefix="gdb -ex run --args">
     <remap from="cloud_in" to="/$(arg kinect_camera_name)/depth_registered/points" />
     <remap from="cloud_out" to="/$(arg kinect_camera_name)/rgb/object_modeling_points_filtered"/>
      <param name="sensor_frame" type="string" value="$(arg kinect_frame_prefix)_rgb_optical_frame" />
      <param name="subsample_value" type="double" value=".005"/>
      <rosparam command="load" file="$(find pr2_object_manipulation_launch)/config/object_modeling_self_filter.yaml" />
  </node>

  <!-- start the Kinect -->
  <include file="$(find rgbd_assembler)/launch/openni_node.launch">
        <arg name="kinect_frame_prefix" value="$(arg kinect_frame_prefix)"/>
        <arg name="kinect_camera_name" value="$(arg kinect_camera_name)"/>
        <arg name="high_res" value="$(arg high_res)"/>
  </include>

</launch>

The segmentation fault is in PCL called from filter on line 105 of self_filter_color.cpp. The backtrace from GDB is: (Unfortunately, I don't have a specially compiled version of PCL and the released one doesn't include debug tags.)

    #0  0x00007ffff6ac8c4f in void pcl::getMinMax3D<pcl::pointxyzrgb>(pcl::PointCloud<pcl::pointxyzrgb> const&, Eigen::Matrix<float, 4,="" 1,="" 0,="" 4,="" 1="">&, Eigen::Matrix<float, 4,="" 1,="" 0,="" 4,="" 1="">&) () from /opt/ros/fuerte/lib/libpcl_filters.so.1.5
    #1  0x00007ffff6ad3cda in pcl::VoxelGrid<pcl::pointxyzrgb>::applyFilter(pcl::PointCloud<pcl::pointxyzrgb>&) ()
       from /opt/ros/fuerte/lib/libpcl_filters.so.1.5
    #2  0x0000000000434867 in filter (output=..., this=0x7fffffffda70) at /opt/ros/fuerte/include/pcl-1.5/pcl/filters/filter.h:117
    #3  SelfFilter::cloudCallback (this=0x7fffffffd560, cloud2=...)
        at /tmp/buildd/ros-fuerte-pr2-object-manipulation-0.6.7/debian/ros-fuerte-pr2-object-manipulation/opt/ros/fuerte/stacks/pr2_object_manipulation/perception/robot_self_filter_color/src/self_filter_color.cpp:105

Playing with the self_filter_color.cpp file has revealed very little. Any hints would be great.

Thanks,

Jenny