shart115's profile - activity

I am trying to run the roslua examples (with fuerte), and am getting the following error:

lua: [string "/home/shart/ros_workspace/roslua/src/roslua..."]:105: Handle message method is neither function nor class

Specifically, this was from when i tried to run the subscriber.lua node.

Any ideas? I just checked out the latest roslua code. Thanks! Steve

Hi, I tried running the pgr_camera_driver from the CCNY stack with my 2MP Grasshopper2 devices, but ran into two problems:

1. the width & height parameters seemed to be reversed, and
2. changing the resolution only cropped the images, it didn't actually change the underlying video mode.

The issues are related, as I noticed the code changes the mode based on a switch statement keyed off the (reversed) width & height. However, even after fixing this, every single video mode I tried came back as "not supported" from the underlying flycap driver.

Anyone have any ideas?

Thanks!

Hi,

We have a pair of Prosilica 2450C GigE cameras that we were trying to calibrate and use with stereo_image_proc---specifically for computing the disparity map and corresponding 3d point cloud.

Trying to do this using full resolution (they are 5MP cameras) created some problems because of limited bandwidth, and a small window (compared to the image size) for the disparity computation (128 pixels). We got an output, it just was very sparse (and slow), not entirely surprisingly.

Instead, we tried to increase the binning of the camera (specifically using a binning value of 4 for both X and Y and resulting in a 612x512 image). We will lose color for these cameras when we do this, but that's not a huge concern right now for us. However, when trying to connect to the disparity topic, we received an error message related to image size mismatch:

$ ROS_NAMESPACE=stereo rosrun stereo_image_proc stereo_image_proc
[ WARN] [1349133972.827883520]: Color topic '/stereo/left/image_color' requested, but raw image data from topic '/stereo/left/image_raw' is grayscale

OpenCV Error: Assertion failed (0 <= roi.x && 0 <= roi.width && roi.x + roi.width <= m.cols && 0 <= roi.y && 0 <= roi.height && roi.y + roi.height <= m.rows) in Mat, file /tmp/buildd/ros-fuerte-opencv2-2.4.2-0precise-20120908-1632/modules/core/src/matrix.cpp, line 322 terminate called after throwing an instance of 'cv::Exception'
  what():  /tmp/buildd/ros-fuerte-opencv2-2.4.2-0precise-20120908-1632/modules/core/src/matrix.cpp:322: error: (-215) 0 <= roi.x && 0 <= roi.width && roi.x + roi.width <= m.cols && 0 <= roi.y && 0 <= roi.height && roi.y + roi.height <= m.rows in function Mat

Aborted (core dumped)

Any body else run into this?
Thanks!

Awesome, that works perfect. Thanks!

Hi, I am trying to retrieve the mesh file names/paths from the robot URDF description. I seem to be able to get all of the other information (link name, mesh origin, parent/child link names, etc.).

Here is my code:

urdf::Model urdfModel;
if (!urdfModel.initParam("robot_description")) {
        ROS_ERROR("Error parsing URDF file...");
        return false;
}
string lnk_name = "/r2/left_palm";
boost::shared_ptr<urdf::Link> lnk;
urdfModel.getLink(lnk_name, lnk);

cout << "what is the type of model: " << viz->geometry->type << endl;
cout << viz->origin.position.x << endl;
cout << viz->origin.position.y << endl;
cout << viz->origin.position.z << endl;

That all works great, but I can't for the life of me figure out where the meshname is stored....

Thanks!

interestingly, when i remove the collision models for the hands and the first shoulder link, rviz shows the visual models as the collision models when i start up the warehouse viewer. that cant be right....

I started looking at just the R2 upper body because I had this working with the arm_navigation some months ago, but have been running into similar issues as I have been with the legs.

Just to minimize the chances of collisions, I reduced all the collision models in the entire robot to about 80%, and unchecked all pairs in the advanced mode of the arm nav wizard.

Tabling for now the fact that if i chose more than one kinematic chain, the warehouse viewer wouldn't start properly for me, I'm still getting collisions for all possible movements. The following picture shows what happens as soon as I move the marker (with the robot visualization at a lower alpha). You can see the smaller collision models, none of which are in contact with each other, show up immediately as red (i.e. in collision). This is true for both arms, even when the (only) kinematic chain I have built the models for are between the chest and the left index finger base!

is the best course of action to go through the URDF to see how many of these collisions I can get rid of?

Thanks, for the response. Using the advanced mode, In most of the collision checks, links show up---despite the ROS-Industrial tutorial blurps often saying that there "should be no reason why this might be the case."

I tried to run the Robonaut2 URDF through the arm_navigation generation tutorial, but it looks like the end-effector is always in collision, and thus i can not generate plans using the planning_components_visualizer.

This is my guess of what's happening based on the end-effector being red upon start up:

and complete inactivity when telling it to "plan" from the menu.

I am using the nasa_r2_common\r2_description\robots\r2c_full_body.urdf.xacro URDF, and choosing the left leg as the 'manipulator' though this seems to work regardless of which of the four limbs i choose.

Is there something i need to check/verify in the advanced wizard to make sure my description is valid?

FYI, I was hoping to push through with the warehouse and motion planning stacks, once I get this working....

Thanks, Steve

any updates on this fix? It is somewhat unclear whether the trunk fixes this issue (and it doesnt look like 1.6.14 has been released yet...

i'm seeing a similar problem with the Robonaut2 simulator since the update as well.

Yeah, I encountered the same problem.

Relevant Bug Report

Hi, I tried getting the arm_navigation tool running with my custom (non-PR2) robot .urdf file and had some issues. The biggest (literally) issue was that my .urdf file uses .stl mesh files that are in inches that are manually scaled to meters. For example:

<mesh filename="package://left_arm.stl" scale=".0254 .0254 .0254"/>

0.0254, being the inches-to-meters scale factor.

Now this all works fine in rviz and gazebo and whatever, but when I run the arm_navigation stack, things go a little crazy---at least in the display. I think the motion planner pieces are working fine, but if you run the planning_components_visualizer tool or the initial wizard to set things up, the green and pink overlays are at the original scale (and thus gigantic).

Anybody seen, or aware of this?

Thanks, Steve