The goals of this lab are

  • Introduction to the ROS’ motion planning tool OMPL
  • Understand the sensor and environments models available in ROS
  • Experimentally evaluate the performance of a sampling-based path planner

Deliverables

  • Design of a challenging motion-planning environment
  • Experimental evaluation of planning time and trajectory length

Duration

  • 3 weeks
Deliverables are due on Monday after the last lab.
Instructions:
  1. Download the OMPL tutorial from the Kavraki lab
  2. Perform the exercises up to Section 7. These were the steps that were taken to import the ClamArm model into OMPL and ROS.
    • Note: in section 4.3 you can skip the step that says echo “source … This part is already setup in the VM.
    • Note: in section 4.5 you can skip the step that says export.. and echo… This part is already setup in the VM.
  3. Construct a planning environment using warehouse elements that requires the arm to reach around an object.
  4. Dig into to the code base to find out
  • where the path is calculated
  • where the path-length is calculated

5. Plan multiple paths for the same motion. Record the path length and planning time distributions.

Viewing Planner Diagnostic Info:

  1. Edit the launch file using:
    rosed pr2_test_arm_navigation ompl_planning.launch
  2. Add
    <param name="publish_diagnostics" type="bool" value="true" />

    right after the

    <param name='default_planner_config...
  3. Now launch the warehouse viewer as described in the tutorial using:
    roslaunch pr2_test_arm_navigation planning_scene_warehouse_viewer_pr2_test.launch
  4. View the diagnostic info:
    rostopic echo -c /ompl_planning/diagnostics

     

 

 

13 Responses to Advanced Robotics Lab #2: Motion Planning

  1. Ben says:

    In section 7 of the OPML tutorial, when I run “move_arm_warehouse create_launch_files.py pr2_test” I get a “couldn’t find package [move_arm_warehouse]” error.  The tutorial seems to think we have this package somewhere, but I can’t seem to find it.  Anyone else having this problem?  

    • Dave says:

      We saw this issue in class today and I believe the fix is to install pr2-desktop as described in section 4.3 running:
      sudo apt-get install ros-electric-pr2-desktop
      We had thought this section wasn’t needed but we were mistaken. 

      • Andy McEvoy says:

        I was having this issue.  Found out that you need to be running the 64 bit version of Ubuntu 11.10.  Also found out that running rviz with intel integrated video cards causes problems (for some people).  Seems like it’s a known issue, but I haven’t been able to find a fix for it.

        Also, found this reference online while looking for more information on OMPL and sampling based motion planning:

        http://planning.cs.uiuc.edu/

    • Sam Pottinger says:

      A little late on this one but, just for future reference and for those hailing from Google, you can also get the move_arm_warehouse package through the through the arm-navigation-experimental stack. You can install that through sudo apt-get install ros-electric-arm-navigation. The official ros docs are a little shy on this point but that package should be available assuming you added the ros repo earlier.

  2. Sam Pottinger says:

    Hello! If you made it sufficiently far in the tutorial but encounter an issue related to the pr2_tabletop_world, you may need to install the pr2 simulator (sudo apt-get install ros-electric-pr2-simulator).

    All the best,
    Sam

  3. Eyal Niv says:

    Have found a few leads on where is the path calculated.
    1. It is possible to set a parameter which is called publish_diagnostics and then subscribe to a topic called ompl_planning
        The parameter has to be set after launching roscore and before launching the warehouse viewer. i.e:
        a.) “roscore & rosparam set /ompl_planning/publish_diagnostics true”
        b.) launch warehouse viewer
        c.) subscribe to a topic called /ompl_planning/diagnostics using “rostopic echo /ompl_planning/diagnostics”
        d.) every time you plan a new trajectory you will see a message saying the planning time and the size of the trajectory.
    2. However, the size is not exactly the path length but the number of waypoints in the trajectory.
    3. There are 2 important packages regarding the ompl.
        a.) ompl  – The actual ompl package
        b.) ompl_ros_interface – An interface package between the ompl package and ros
        The length is calculated inside the solvers on the ompl package which shares only its header.
        Under ompl/installation/include/ompl/geometric you’ll be able to find the IK solvers which inherits a more general Planners class and a PathGeometric class.
        PathGeometric class inherits the length method from a Path class which you can find defined under ompl/installation/include/ompl/base/Path.h
        c.) The ompl_ros_interface calls a service “/ompl_planning/plan_kinematic_path” which is served by the ompl package to get the IK solution. That service is of
             type GetMotionPlan under the arm_navigation_msgs/srv
        d.) The trajectory that it returns as a response doesn’t include the length of the path, however, the size (As mentioned above) is included.

    This is as far as I got.
    Eyal

  4. Ben says:

    So, the instructions above seem to be working, I’m getting something that looks like this:

    summary: Planning Succeededgroup: left_armplanner: SBLkConfig1result: Successplanning_time: 0.244019trajectory_size: 81trajectory_duration: 0.0state_allocator_size: 0

    I’m assuming the trajectory_size parameter is the number of waypoints?  I thought this might change between runs, but I’ve done about 20 runs so far and it’s been constant.  Am I looking at the right thing?

    • Eyal Niv says:

       You might have tried a very simple motion plan. Constructing a more complex one should generally give you a varying number of waypoints for each new trajectory .

  5. Charles Dietrich says:

    Two comments: 1) finding the path and 2) changing the planner.

    Re: the path, I reasoned as follows: rviz knows the approximate path (say of the wrist joint), since it displays it when the play button is pressed in warehouse viewer. Therefore, there must be 1) a topic that provides that information 2) tells rviz to draw a path. The path that rviz gets is better than just knowing the number of points in the path, even if the rviz path is not the best available data. I looked into topics of type MarkerArray, there are several. These contain (x,y,z) tuples but I didn’t figure out how they correspond to the path of a joint.

    Re: the planner, it is specified in a yaml file in the package in ~/ros. So it might be trivial to change the planner.

Leave a Reply

Set your Twitter account name in your settings to use the TwitterBar Section.