ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

ROS electric arm_navigation architecture questions

asked 2011-10-10 22:55:11 -0500

Ibrahim gravatar image

Hi all,

I started to realize that I'm not actually entirely sure how I'm supposed to use arm_navigation in my own code for the PR2. I was trying to insert my own meshes programmatically as collision objects which I got to work thanks to E. Gil Jones, but I can't seem to figure out how to visualize what's happening. I ran the planning_scene_warehouse_viewer but while this launches an environment_server which subscribes to collision_object (which I have checked is being published to) it doesn't seem to visualize the mesh that I inserted in rviz, whereas if I insert the mesh using the GUI it does show it in rviz. This is slightly annoying because I want to send goals to the planner to test it out but I can't see where my obstacles are exactly so I don't know whether it's working correctly.

I think at a high level I'm not entirely sure what launch files I'm supposed to be launching and interacting with. If I'm just writing code, not using the warehouse viewer, should I be using the launch files in pr2_3dnav as in previous releases of move_arm? What is the relationship between arm_navigation and move_arm?

At a high level again, what I want to do is take some sensory data, fit some mesh that I've got ahead of time to something in the real world, and then plan around this object. I can do the first few parts, but I'm not actually sure what I should be sending the motion planning request to and what general setup I should have before my code is running. What is the "correct" or suggested way to do this in ROS electric? Thanks very much!

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2011-10-11 05:32:05 -0500

egiljones gravatar image


Understanding how all the components fit together is indeed complicated, as things get a bit hairy architecturally. You are correct that when you start building applications that use arm_navigation you'll want to launch things that look like pr2_3dnav - this launches the environment_server with the use_monitor and use_collision_map flags set to true, and brings up kinematics and move_arm nodes for each of your arms. move_arm is a package that exists within the arm_navigation stack, and that's still true in Electric. One difference is that the packages in several other stacks are now also included in the arm_navigation stack.

During the phase of testing your application, however, it may be useful to run the warehouse viewer. First, you should be able to visualize the mesh objects you've published to the environment server by using the "Refresh planning scene..." menu item in the warehouse viewer. The environment_server will not push new information provided from other channels to the warehouse_viewer, but once the warehouse viewer asks for the new information it will be provided. This tutorial may provide some information - the warehouse viewer interacts with the system in much the same way the planning_components_visualizer does. Note that you should make sure when using the warehouse viewer with a running system that the "Use robot data" check-box in the initial configuration screen is checked. This mode will likely be of use in testing as long as you regularly refresh the planning scene, though it's not as well tested as some of other ways of using the warehouse.

The other way we've used the warehouse viewer is on data that's been automatically logged by the rest of the system. We actually have a version of the main move_arm node that is set up to log to a database. Thus you can attempt your code by calling move_arm and then use the warehouse viewer after the fact to inspect the planning scene, the resulting MotionPlanRequests and trajectories, and to issue new commands. There's not a launch file in pr2_3dnav that launches this version of move_arm, but I'm in the process of adding one and will be releasing shortly.

To conclude, you should be able to fulfill your high-level goals in either of the modes. In the first mode you'll be acting instead of move_arm, and in the second mode you'll be issuing MoveArmAction requests to move_arm which will then execute them, and log the results if you are using the experimental version. Let me know if you have addition questions, and I'll add a comment to this thread when the new version of pr2_arm_navigation is out.

edit flag offensive delete link more

Question Tools

1 follower


Asked: 2011-10-10 22:55:11 -0500

Seen: 345 times

Last updated: Oct 11 '11