mrath's profile - activity

We recently switched some of our ROS development from a bunch of custom dependency install (bash) scripts to rosdep. Some of them we created proper .rdmanifest files for, including the depends tag.

However, the installation order doesn't work as expected. At the bottom is an example output, from adding an echo statement to each check presence script. We can see a couple of things from this:

1. The check presence scripts are executed twice, for some reason
2. The first time, the order is correct (e.g. rcw_statistics_database depends on lamp) - the second time it's wrong
3. When installation begins, it uses the wrong order (the second one)

What could be the cause of this? Let me know if you need more info.

$ rosdep install -y -i --from-paths /home/builder/RCW_workspaces/rcw_ci_ws/src
check-presence-script: ros_patches
​check-presence-script: lamp
check-presence-script: mysql-connector
check-presence-script: rcw_database
check-presence-script: robwork
check-presence-script: rcw_statistics_database
check-presence-script: smile

(here it is installing one dependency through apt, that has nothing to do with this)

check-presence-script: mysql-connector
check-presence-script: smile
check-presence-script: rcw_statistics_database
check-presence-script: lamp
check-presence-script: rcw_database
check-presence-script: robwork

executing command [rosdep-source install http://some_url/mysql_connector.rdmanifest]
executing command [rosdep-source install http://some_url/smile.rdmanifest]
executing command [rosdep-source install http://some_url/rcw_statistics_database.rdmanifest]​

(installation fails due to missing dependencies)

Hey all

I need to get the current state of the robot, including spatial description, as a CAD file or a pointcloud for further processing. Specifically, I need to get the complete 3D description of the complete URDF model, in the current state/joint configuration, in a format that PCL can use.

I am not really sure how to do this, but I can see a partial solution, and would appreciate your feedback.

1. Load the URDF
2. Use geometric_shapes to parse all links into bodies
3. Do raytracing on all bodies to get a set of points for each body
4. Collect the points for each body into one point cloud or CAD file.

The question is how to merge this into one output in 4.? Or if there's an easier/more efficient solution that I've missed?

Thanks.

Well.. This is awkward. Apparently the robot needed a good rest over the weekend, and the navigation is now working. I suspect I might have forgot to restart the computer at some point, even though I don't like to admit it. Marking as solved for now.

Problem fixed when upgrading from Fuerte to Hydro.

Sometime in March, possibly after upgrading to Hydro, navigation on our robot stopped working. It wasn't critical for our use at the time, but it is now.

After investigating a bit, it seems like the problem is that the local costmap is not aligned with the static map, and thus the robot thinks it's in collision even when it's not. This is the output when sending a goal in such a situation:

[ WARN] [1406897186.158511056]: Clearing costmap to unstuck robot.
[ WARN] [1406897187.003142197]: Rotate recovery behavior started.
[ERROR] [1406897187.003483173]: Rotate recovery can't rotate in place because there is a potential collision. Cost: -1.00
[ WARN] [1406897187.793568508]: Clearing costmap to unstuck robot.
[ WARN] [1406897188.727111389]: Rotate recovery behavior started.
[ERROR] [1406897188.727278521]: Rotate recovery can't rotate in place because there is a potential collision. Cost: -1.00
[ERROR] [1406897189.489224920]: Aborting because a valid control could not be found. Even after executing all recovery behaviors

And this is how it looks in Rviz, when I visualize the local costmap. Clearly, something is wrong:

In the costmap_local config file, I have set the parameters exactly like they where before things went wrong, which is like it is in the tutorial as well. I tried changing to global_frame: map and static_map: true but that didn't work.

I tried installing the 1.11.5 release of the navigation stack (instead of the current hydro version), but that didn't work either.

Any help is appreciated!

Hello all, I'm trying to run this tutorial, but rosbag fails to record data. I tried both the specified instructions

rosbag record -a

as well as recording a single topic

rosbag record /turtle1/command_velocity

but either results in the same error:

Traceback (most recent call last):
  File "/Users/mrath/ros/ros/bin/rosbag", line 35, in <module>
    rosbag.rosbagmain()
  File "/Users/mrath/ros/ros_comm/tools/rosbag/src/rosbag/rosbag_main.py", line 807, in rosbagmain
    cmds[cmd](argv[2:])
  File "/Users/mrath/ros/ros_comm/tools/rosbag/src/rosbag/rosbag_main.py", line 115, in record_cmd
    os.execv(recordpath, cmd)
OSError: [Errno 2] No such file or directory

I'm running ROS in OS X Lion, which I suppose is the problem, but I have no clue to the solution, so please advise.

Ok, I know have gotten a simple example to work. I discarded everything I had and wrote a simple Python node, that can successfully attach an object and remove it again.

I guess it was indeed poor understanding of how the arm_navigation stack works, as it seems like the following is the procedure that works.

For attaching:

• Add CollisionObject to collision_objects in the planning scene using the /environment_server/set_planning_scene_diff service
• Publish CollisionObject on the /collision_object topic
• Publish AttachedCollisionObject on the /attached_collision_object topic

For removing attached objects:

• Using the same topic and message as point 3 above, with the following settings:

  rm_object = arm_navigation_msgs.msg.AttachedCollisionObject()
  rm_object.link_name = rm_object.REMOVE_ALL_ATTACHED_OBJECTS
  rm_object.object.operation.operation = rm_object.object.operation.REMOVE
  

• The planning scene then needs to be refreshed, as @bit-pirate pointed out. Do this be sending an empty GetPlanningSceneRequest to environment_server/set_planning_scene_diff

Can you elaborate? I tried getting the current planning scene, and sending that one back, but with empty arrays for attached_collision_objects and collision_objects

I am doing manipulation with the PR2, and have trouble with removing a collision model I added earlier. I realize that this might be because I don't fully comprehend how the arm_navigation stack works.

I am adding the collision model of the picked object to the collision map, and subsequently adding it as an attached object. I have tried using the /environment_server/set_planning_scene_diff service, but this fails to even add the collision model in the first place.

So I first add it by publishing a CollisionObject message on /collision_object and then an AttachedCollsionObject message on /attached_collision_object. This works fine for attaching the object, as I can see it on the /attached_objects marker in Rviz and I can send MoveArm goals afterwards.

However, none of the following work for removal of the collision object after placing it:

In terminal:

rosservice call /collider_node/reset "{}"

In node:

reset_object = arm_nav_msg.AttachedCollisionObject()
reset_object.link_name = "all"
reset_object.object.header.stamp = rospy.Time.now()
reset_object.object.header.frame_id = "/base_link"
reset_object.object.operation.operation = reset_object.object.operation.REMOVE
reset_object.object.id = "all"
attach_pub.publish(reset_object) # Publishes to /attached_collision_object
collision_pub.publish(reset_object.object) # Publishes to /collision_object

Even though this is the only ways to do it I could come across. It is still there in Rviz, and arm navigation fails, since the gripper has moved, and is now "in contact" with the attached object (which hasn't been removed).

Obviously, restarting the arm navigation does the trick, but that shouldn't really be necessary, eh?

I have not tried that, no, it seemed like to much trouble at the time. In the meantime I've lived with the bad model colors (remember this is only for visuals), but I might check that out at some point. Thanks.

This is more a curiosity than an actual problem.

Yesterday morning, I started gazebo, and it ran smoothly throughout my work day (which is great, first time that happened). When I left, I forgot to turn of my workstation, and when I got back this morning, the PR2 had moved a little. Looking back, I remember noticing this towards the end of the day yesterday (simulation time approx 9-10 hours) as well, but didn't pay much attention to it.

What is the reason for this? I haven't used a single node that has anything to do with the base.

Attached is a screenshot of the current Gazebo state. The robot is supposed to be in front of the middle of the table (where the coke cans are).

I think it is indeed infinitesimal reaction forces that causes this, it's a common problem in explicit simulation. Worth noting if you're running a long simulation where the robot is supposed to be fixed at all times.

oh, and obviously I did indeed write to Matei, and he did fix it

I'm following the guide on the wiki. I have installed the database on my desktop, which works fine. However, on the robot I would like to access the database remotely. I launch with

$ roslaunch household_objects_database objects_database_remote_client.launch

which seems fine. However, when calling one of the remapped services, I get return code 3. I've tried both ping grasp.willowgarage.com and telnet grasp.willowgarage.com 15432 which also work fine, so I guess it's not a network problem.

The same error occurs on both the robot and my desktop.

The issue is very similar (i.e. identical) to this one.

UPDATE: I tried it from my home network as well, and there is still no connection, and still replies with error code 3. I'm surprised no one knows how to fix this.