Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Addition of CHOMP planning adapter for optimizing result of other planners #1012

Conversation

raghavendersahdev
Copy link
Contributor

@raghavendersahdev raghavendersahdev commented Aug 1, 2018

Addition of CHOMP planning adapter to act as an additional optimizer for other planners like OMPL

This PR is a work done by Raghavender as a part of 2018 Google summer of code. As a part of this PR, CHOMP planning adapter works and can be used as an additional optimization technique in combination with other motion planners like OMPL.

With this PR, CHOMP can act as a post-processor for other planners. one simply needs to add a line in their ompl_planning_pipeline.yaml file if they want to use this. Just add this line in your planning_adapter= > default_planner_request_adapters/CHOMPOptimizerAdapter to add CHOMP a an additional post-processing optimizer.
Corresponding Tutorials PR available here!

Checklist

  • addition of CHOMP planning adapter in the planning_request_adapter folder.
  • added code in chomp planner folder. Addition of functionality in CHOMP to receive input paths obtained from OMPL and act as an optimizer.
  • updated planning_scene.h and planning_scene.cpp; Added code in the planning_scene folder to make certain variables mutable and addition of constant version of certain functions.

@raghavendersahdev
Copy link
Contributor Author

Hi @davetcoleman @mamoll this PR is ready for review.

@@ -129,6 +132,11 @@ class ChompTrajectory
*/
void fillInCubicInterpolation();

/**
* \brief receives the path obtained from OMPL and puts it into the appropriate trajectory format required for CHOMP
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is MotionPlanDetailedResponse really OMPL-specific or can the trajectory be produced by other planners? If it's not OMPL-specific, then rename this to initializeWithTrajectory or something like that.

Copy link
Contributor Author

@raghavendersahdev raghavendersahdev Aug 2, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually trajectory from STOMP can also be made to work with MotionPlanDetailedResponse as in here . I can possibly change it to initializeWithTrajectory

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done ! replaced function name with fillInFromTrajectory()

int num_joints_trajectory = trajectory_msgs.joint_trajectory.points[0].positions.size();

// variables for populating the CHOMP trajectory with correct number of trajectory points
int repeated_factor = num_chomp_trajectory_points / num_response_points;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would be 0 if num_response_points>num_chomp_trajectory_points

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes you are correct, I will write another way of setting of the trajectory whenever num_response>num_chomp_trajectory_points. For chomp there are generally 100 points and OMPL produces less than 100 points almost always, but I get it, I will implement another way of loading of trajectory for num_response_points > chomp_trajectory_points

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done! implemented a simple decimation down sampling of the input trajectory to address this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

per @mamoll, you should add error checking and return false if the input trajectory_msgs has no points

res.trajectory_ = res_detailed.trajectory_[0];
res.planning_time_ = res_detailed.processing_time_[0];
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the initial trajectory is valid, but CHOMP makes it invalid, does the planning adaptor return the initial trajectory?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it should as per this block, if planning_success from CHOMP is false, then the res MotionPlanDetailedResponse object is never changed from CHOMP and should stay the same as obtained from OMPL as this is the only place where the response trajectory is changed in the chomp_optimizer_adapter.cpp apart from being set initially here in the OMPL planner.

* checker for a constant planning scene whenever required, e.g., for some planners like CHOMP
*/
const void
addCollisionDetector_ConstVersion(const collision_detection::CollisionDetectorAllocatorPtr& allocator) const;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no _ underscore in function name

Also remove "Version" from function name

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure will do

@@ -246,6 +246,14 @@ class PlanningScene : private boost::noncopyable, public std::enable_shared_from
* */
void addCollisionDetector(const collision_detection::CollisionDetectorAllocatorPtr& allocator);

/** \brief Add a new collision detector type.
*
* this is the constant version of the function addCollisionDetector(), it is added here for changing the collision
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Capitalize "this" at start of sentence here and below

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

* this is the constant version of the function setActiveCollisionDetector(), it is added here for setting the
* collision checker for a constant planning scene whenever required, e.g., for some planners like CHOMP
*/
const void setActiveCollisionDetector_ConstVersion(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no _ underscore in function name

Also remove "Version" from function name

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

* name of a collision detector that has been previously added with
* addCollisionDetector_ConstVersion().
*/
const bool setActiveCollisionDetector_ConstVersion(const std::string& collision_detector_name) const;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no _ underscore in function name

Also remove "Version" from function name

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done


virtual std::string getDescription() const
{
return "CHOMP Optimizer !!!!";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

more professional (no !)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh yeah sure !! removed.

// populate the trajectory to pass to CHOMPPlanner::solve() method. Obtain trajectory from OMPL's
// planning_interface::MotionPlanResponse object and put / populate it in the
// moveit_msgs::MotionPlanDetailedResponse object
moveit_msgs::RobotTrajectory trajectory_msgs2;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

better variable name than "2"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

changed to trajectory_msg_from_response


chomp::ChompPlanner chompPlanner;
planning_interface::MotionPlanDetailedResponse res_detailed;
moveit_msgs::MotionPlanDetailedResponse res2;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

better var name than 2

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

changed to res_detailed_moveit_msgs


bool planning_success;

bool temp = chompPlanner.solve(planning_scene, req, params_, res2);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you don't need temp and planning_success, combine them

@@ -34,5 +34,10 @@
<description>
</description>
</class>

<class name="default_planner_request_adapters/CHOMPOptimizerAdapter" type="default_planner_request_adapters::CHOMPOptimizerAdapter" base_class_type="planning_request_adapter::PlanningRequestAdapter">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

add line break instead of word wrap usage

Copy link
Contributor Author

@raghavendersahdev raghavendersahdev Aug 7, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

all others classes/plugins in the planning_request_adapters_plugin_description.xml file also had a word wrap usage and not a line break, so I kept this as word wrap for now. I can change everything to line break, but I think it should be word wrap for all (I maybe wrong).

@davetcoleman
Copy link
Member

is this ready for review again?

@raghavendersahdev
Copy link
Contributor Author

yes

@mamoll
Copy link
Contributor

mamoll commented Aug 10, 2018

👍 looks good to me.

@davetcoleman
Copy link
Member

travis failed, i just restarted it

@raghavendersahdev
Copy link
Contributor Author

it still failed after you restarted, I just committed a a sample dot, to restart travis to double check, last time something similar happened to another of my PRs in moveit_tutorials, I just made a sample commit and it passed..lets see this time

@raghavendersahdev
Copy link
Contributor Author

raghavendersahdev commented Aug 22, 2018

Ok so now travis passes which is good but weird, maybe my guess is when its only restarted it might be picking up some form of CMakeCache file but when a commit is made it restarts from scratch, I don't exactly know travis functionality so I may be wrong here.

@davetcoleman
Copy link
Member

Travis failed:

Errors << moveit_ros_planning:cmake /root/ws_moveit/logs/moveit_ros_planning/build.cmake.000.log
CMake Warning at /opt/ros/kinetic/share/catkin/cmake/catkinConfig.cmake:76 (find_package):
Could not find a package configuration file provided by
"chomp_motion_planner" with any of the following names:

I'm guessing you are missing a dependency on chomp_motion_planner in moveit_ros_planning

@raghavendersahdev
Copy link
Contributor Author

resolved merge conflicts by re-basing the PR and Travis passes currently

@davetcoleman davetcoleman merged commit b84b1bf into moveit:kinetic-devel Oct 13, 2018
@rhaschke rhaschke mentioned this pull request Oct 15, 2018
@rhaschke
Copy link
Contributor

As a note for others: This merged PR currently breaks kinetic-devel. There is a fix available (#1086), waiting for approval and merge.

@simonschmeisser
Copy link
Contributor

strange, why did this compile here? Shouldn't it have failed due to the missing package.xml entry here as well as it does in kinetic-devel (and on our internal build server)

@rhaschke
Copy link
Contributor

rhaschke commented Oct 15, 2018

strange, why did this compile here?

Probably, it was simply build-order luck that it compiled here.

rhaschke added a commit that referenced this pull request Oct 17, 2018
rhaschke pushed a commit to ubi-agni/moveit that referenced this pull request Oct 17, 2018
…nners (moveit#1012)

* added functionality for CHOMP Optimization Adapter and made some changes in planning_scene.h / .cpp files to make this work
* added functionality for optimizing path obtained from OMPL, under construction but works fine right now
* added functionality to initialize trajectories in CHOMP when input trajectory has more points than CHOMP trajectory points
* hotfix moveit#1086
@raghavendersahdev
Copy link
Contributor Author

The way travis function sometimes confuses me, I wonder if there is a tutorial on its functionality somewhere online . . Sorry for temporarily breaking kinetic-devel , my bad ; In my defense, I was blindly dependent on travis results to ensure clean builds . .

@rhaschke
Copy link
Contributor

This wasn't your fault. It's our task as maintainers to actually ensure that nothing breaks.

@simonschmeisser
Copy link
Contributor

I don't think this is related to travis ...
You did not include the dependency on chomp_planner in package.xml, therefore catkin tools did not know that it has to build packages in a specific order. (ie chomp_planner before the failing dependent package). So sometimes it did build it before, sometimes after. You could have observed the same behaviour "offline" if you rebuild the whole workspace from scratch (catkin clean all)

I remember seeing warnings/errors about cases like this some time ago, was that check pre catkin tools?

@raghavendersahdev
Copy link
Contributor Author

raghavendersahdev commented Oct 17, 2018

thanks @rhaschke ; @simonschmeisser On these lines I have a small quick question, do you know a way to ensure that certain packages are built in a specific order, in this case how would you ensure chomp_planner package is built before some of its other packages on which it might depend (here =Planning_request_adapters package)...

I am asking this as I observed this in my code while I was creating the STOMP planning adapter in my PR #1081 , which involved stomp_moveit package to be built before the planning_adapters is complied/built... I was getting a similar issue, I kind of pseudo hacked it on my local machine to install stomp_moveit and then reinstall moveit so that Planning adapters reads that package... but is there a concrete legit way to handle these order of builds in catkin...

@raghavendersahdev
Copy link
Contributor Author

Or is releasing as a debian only the way

@simonschmeisser
Copy link
Contributor

no, having a dependency (stomp_moveit) in in package.xml (of planning_adapters) should ensure that stomp_moveit gets build before planning_adapters

@raghavendersahdev
Copy link
Contributor Author

oh Yes you are right, thanks 👍 I did not do that, will do that

@simonschmeisser
Copy link
Contributor

Note that the right thing to do would be to move the adapter to it's own package in one of the chomp sub-directories to a) resolve this dependency inversion b) make it possible to CATKIN_IGNORE chomp completely and c) make it possible to release MoveIt! without it

find_package(Boost REQUIRED)

include_directories(
../../../moveit_planners/chomp/chomp_motion_planner/include/
Copy link
Contributor

@130s 130s Oct 24, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry if I missed any discussion, but is relative path a good way to find resource?

I'm afraid using relative path of another package would limit the portability of a package.

Copy link
Contributor

@130s 130s Oct 24, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess with the suggestion in #1012 (comment) we'll be able to replace this hardcoded relative path with auto-substituted path.

pull bot pushed a commit to shadow-robot/moveit that referenced this pull request Sep 3, 2020
…nners (moveit#1012)

* added funcitonality for CHOMP Optimization Adapter and made some changes in planning_scene.h / .cpp files to make this work

* added comments and cleaned up some code

* added funcitonality for optimizing path obtained from OMPL, underconstruction but works fine right now

* did some commenting and cleaning up of code

* cleaned up some code and added comments

* corrected my previous public/private small  bug in planning_scene.h

* changed CHOMP Parameter name to make more sense trajectory_initialization_method

* added functionality to initialize trajectories in CHOMP when input trajectory has more points than CHOMP trajectory points

* changed author for chomp_optimizer_adapter.cpp

* addressed Dave's PR requested changes

* addressed PR requested changes added a new helper function to make chomp_initialization from trajectory simpler, now has if, for, for

* changed OMPL to fillTrajectory as the parameter value

* just a dot

* added chomp_motion_planner dependency in moveit_ros_planning
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants