Home

Welcome to the monolithic_pr2_planner wiki!

This wiki is not only about the monolithic_pr2_planner but also documents the changes I made in its dependencies while migration.

I plan to do the migration in two steps:

1. Migrate from rosbuild (groovy) to catkin (groovy).

2. Migrate from catkin(groovy) to catkin(indigo).

I expect the step 1 to mostly involve boilerplate code, for which I am using catkinize package.

Note

1. Packages with minimal dependencies: leatherman, sbpl_geometry_utils, ikfast_pr2 (on orocos_kdl)

1. Rosbuild to Catkin (groovy)

Packages whose debian source are not available through apt-get:

deb http://us.archive.ubuntu.com/ubuntu vivid main universe

1. leatherman : groovy(catkin) version available in aurone's account. He also has the indigo version.

2. sbpl_geometry_utils: groovy(catkin) version available at sbpl's account. It doesn't seem to have an indigo version. For pr2_collision_checker, I am using an older version of the master in groovy_catkin. I have basically removed a few commits that introduced API changes in sbpl_collision_checker`.

3. sbpl_manipulation_components: Only groovy(rosbuild) version available at bcohen. It requires the library distance_field available as a package of the metapackage moveit_core. The groovy_catkin branch works with ros-groovy-moveit-core. It is basically the catkinized version of the groovy branch.

4. pr2_arm_kinematics/pr2_kinematics: Depends on arm_navigation metapackage whose packages are now part of Moveit, including kinematics_base, kinematics_msgs, etc. Hence, I am using the hydro version, which has migrated to Moveit. Its hydro version also works for indigo.

5. pviz: pviz works on groovy_catkin.

6. pr2_collision_checker: Catkinized version here. Depends on pr2_arm_navigation. Doesn't have an indigo version. It doesn't work with hyrdo version of pr2_kinematics. Should I migrate pr2_collision_checker's API to hydro of pr2_kinematics or should I migrate groovy branch of pr2_kinematics to Moveit from navigation? **I migrated pr2_collision_checker to hydro of pr2_kinematics.

7. bfs3d: Part of sbpl_manipulation.

8. navigation/costmap_2d: Part of the navigation stack. All versions available including catkinized version of groovy in the git repo. groovy(catkin) is available here as a reduced navigation metapackage. This is proving to be a pain in the indigo version. There has been an API change from groovy to hydro! What to do? Try to make code work with groovy version or port code to indigo version of navigation?

Dependencies available via apt-get:

1. geometric_shapes: All versions avaialble.

2. pr2_arm_kinematics: All versions available as part of pr2_kinematics stack/metapackage. However there is no groovy(catkin) version.

3. arm_navigation_msgs * : Package has been deprecated and is available as part of the arm_navigation stack. Its replacement is the Moveit package. Following is an example of porting to Moveit. There has been a change in API in the moveit_msgs port of arm_navigation msgs, at least in OrientedBoundedBox.h. Better to use arm_navigation_msgs and upgrade to moveit_msgs if need be.

4. orocos_kdl : It is the replacement of kdl package and all versions are available.

5. distance_field: It is available as part of the moveit_core package. The groovy version works.

6. kinematics_msgs: It is available as part of moveit_msgs. Should I migrate to moveit or use a catkinized version?

7. ompl: ros-groovy-ompl does not work with the code. Install a highter version via apt-get. I had to comment out the 2nd argument used while constructing PathLengthOptimization function as ompl has only one argument version. Find out the use of the 2nd one

8. octomap_mapping: Required at runtime. All versions available.

9. pcl_conversions: Being used in indigo instead of pcl/conversions.h.

*: Potential difficult issues.

Groovy to Indigo

So, there seems to be issues with the distance field being generated. The function that is supposed to return the distance to the nearest obstacles getDistance always returns 0.4 (max), meaning it thinks there is not obstacle.

I am trying to visualize the distance field. OccupancyGrid has a function getVisualization that returns marker array of the field. It is used via the singleton OccupancyGridUser' class. HeuristicMgrderives fromOccupancyGridUseras do all heuristcs defined in theHeuristicsfolder (they also derive fromAbstractHeuristic`.

CollisionSpaceMgr handles collision checking for the Pr2. It is used via the variable m_cspace_mgr and contains a CollisionSpace called m_space. It also derives from OccupancyGridUser.

The Environment class contains a node handle and instances of the above classes.

loadMap and updateMap are the functions that update the distance field.

• The visualization of the generated plan is not working probably because of the code I have commented out. Have a look at that.