ROS electric arm_navigation architecture questions

edit

Ibrahim,

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.