JuergenHess's profile - activity

Hi,

I don't think there is a "pr2all" package in electric. "ros-cturtle-pr2all" means you are looking for a cturtle package but actually you are using electric.

Maybe you can try installing the ros-electric-pr2-tabletop-manipulation-apps package and follow these tutorials: http://www.ros.org/wiki/pr2_pick_and_place.

Best, Juergen

Thanks for the clarification. I changed my joint trajectory accordingly. It works fine.

See my answer to the other question you asked.

It happens for intermediate points. I think that I can recall a case where it also happend for the first one but I am not sure. I did not look out for that at the time.

Hi,

in ROS Electric the controller moved to the robot_mechanism_controllers package.

In the launch file you had to create during the tutorial, change the controller type from "JTTeleopController" to "robot_mechanism_controllers/JTCartesianController". Then it should work.

Best, Juergen

Hi all,

I have a couple of problems with using the Joint Spline Trajectory Controller on the PR2. I used the controller through the provided action interface and followed this tutorial: http://www.ros.org/wiki/pr2_controllers/Tutorials/Moving%20the%20arm%20using%20the%20Joint%20Trajectory%20Action

Here are my questions:

1. For the continuous joints, in a few cases, the joint rotates towards the direction of the larger angle instead of the smaller one. The angles I am sending to the controller are normalized. How can I make sure I am rotating about the smaller angle?

2. The state publisher does not seem to normalize the angle of the continuous joints. Is that the correct behavior?

Best, Juergen

Hi all,

we are using ROS Electric and have installed the perception_pcl stack which is supposed to come with PCL1.1. The files related to the OpenNIGrabber seem not to be available in the stack. That is for Ubuntu 10.04 and 11.04 64Bit packages.

I am confused as the grabber was introduced in version 1.0. I thought the perception_pcl stack would provide same functionality as the standalone version.

Here is my file listing of the folder where I think the grabber should be in: cd /opt/ros/electric/stacks/perception_pcl/pcl/include/pcl-1.1/pcl/io $ ls -rw-r--r-- 1 root root 15K 2011-08-31 22:56 file_io.h drwxr-xr-x 2 root root 4,0K 2011-09-14 12:05 impl -rw-r--r-- 1 root root 15K 2011-08-31 22:56 io.h -rw-r--r-- 1 root root 20K 2011-08-31 22:56 pcd_io.h -rw-r--r-- 1 root root 2,8K 2011-08-31 22:56 pcl_io_exception.h -rw-r--r-- 1 root root 2,3K 2011-08-31 22:56 vtk_io.h

I also ran "locate grabber.h" but without any result. Is that by purpose? Does the grabber not work with ROS or the openni ROS package somehow or is the ROS package structured differently?

Thanks for your help.

Juergen

Hi Sarah,

I don't think that is the same controller. A quick vimdiff on the source showed too many differences. I guess there are different cartesian controllers. If you need the teleop_controller package you can just download from here: https://code.ros.org/svn/wg-ros-pkg/stacks/pr2_cockpit/trunk/teleop_controllers and compile it. That worked for me. I don't don't know if and when the pr2_cockpit stack will be available for Electric as a Debian package.

Juergen

The base_local_planner::CostmapModel will help you do these footprint checks pretty easily. You can check out the documentation here. Basically, you'll create the CostmapModel object by passing it a reference to a costmap_2d::Costmap2D object, and then call footprintCost on it. If the cost is negative, that footprint position is in collision with an object. I should also mention that this is the internal API of the navigation stack, so stability isn't guaranteed, but things haven't changed with that code in awhile so you should probably be OK.

Great. Thanks. I will try that.

Hi,

I would like to evaluate if a larger set of robot base poses (maybe 200-300) is in collision. More specifically, I would like to know if the robot footprint is in collision with the environment. I do not need to make a motion plan.

Has anyone done that before? I have been reading through the tutorials, especially those of the navigation stack but have not found anything suitable.

Right now, my best guess of how that could be accomplished is through adding a service to the move_base node in the navigation stack, as all required information is available there. However, I think this would mean changing a lot of the code (the move_base node, the base_global_planner interface in nav_core, etc.)

So if anyone has a suggestion for another or easier solution, please let me know.

Cheers,

Juergen

We solved it. We were a little confused by the unused type of the mesh and had a bug in the code. It is working now. Thanks. Juergen + Phillip

Hi Scott,

I just tried it today and it almost worked right away. The only thing that the tutorial at http://www.ros.org/wiki/rgbdslam did not mention was that you have to use the experimental version of the octomap stack. I changed the tutorial accordingly. Other than that, it worked as expected.

Juergen

Hi all,

I am using dynamic_reconfigure a lot for passing parameters and changing them at runtime. Thus far it worked great. Now I tried to change the namespace of the node in a launch file, for example:

< node ns="learning" name="$(anon foo)" pkg="rospy_tutorials" type="talker" />

It works fine and the node shows up as "/learning/talker" but the node is now not listed in the dynamic_reconfigure gui anymore and is not passed the default arguments. Is this a bug or am I doing something wrong? I am using Ubuntu 10.04 and Diamondback.

Thanks,

Juergen