THIS REPO HAS MOVED TO https://github.com/ros-planning/moveit
The new location as of August 5th, 2016 is https://github.com/ros-planning/moveit
See migration notes for more details.
Please do not open new pull requests or issues in this old location.
I've just checked out moveit sources using http://moveit.ros.org/wiki/index.php/Groovy/Installation
Making them gives:
moveit_planners/ompl/ompl_interface/src/ompl_interface.cpp:98:60: error: ‘const class planning_scene::PlanningScene’ has no member named ‘getCurrentStateUpdated’
This code comes from the latest commit, so I assume that the just mentioned latest commit relies on some code that's not committed yet.
A possible alternative is that the build process doesn't respect a correct build order, and tries to link to the version of library that was installed through the binary install before (rather than trying to build the packages in the correct order and using the locally built version), but my knowledge of the build process and moveit stack is limited. All I can confidently tell is that I've followed the instructions and the build failed, so tips and corrections are appreciated. Is there a way to build moveit without removing the binary moveit?
My use case is to have two different planning pipelines, say one for ompl and one for my stuff, called cat. The problem is that planner plugins assume the configuration parameters will be found in the home namespace, which doesn't allow for different configurations for different planner instances.
Some more detail: I load the plugin parameters in namespace ~/ompl and ~/cat. The planning pipelines take arguments for what the parameter names are, so you can prepend ompl/ and cat/ to the strings. However, the actual planner plugins assume they will find the planner configurations in the home namespace. There needs to be some way of telling the plugin that it has been pushed down into another namespace.
Last release into Indigo was more than an year ago (Oct 2014).
Thanks!
In order to create smooth paths for physical robot arm execution I need to raise the number of interpolated points generated by OMPL.
File: ompl/core/ompl_interface/src/model_based_planning_context.cpp
Line: 243
Code: pg.interpolate((std::size_t)floor(0.5 + pg.length() / max_solution_segment_length_));
The mechanism for loading parameters from the ROS parameter server of the ompl_interface is a protected function loadPlannerConfigurations() run only on construction.
Many planner parameters drastically change the performance of the planner, and it would be nice to be able to change these on the fly without having to restart the move_group node. For example, the parameter "range" indicates how far toward some random c-space point the random planner will attempt to move to create each waypoint. When this value is small, one tends to get intricate plans closely skirting objects. When it is large, the plans tend to move way out of the way.
See http://www.ros.org/debbuild/indigo.html
The sourcedeb is built, binary is failing on all platforms, this makes most of moveit uninstallable.
Heads up to @sachinchitta @tfoote
This commit from the latest OMPL will potentially break MoveIt!
ompl/ompl@78f5b68#commitcomment-7855991
IMHO we should leave getDefaultPlanners in OMPL's SimpleSetup in the short run, marked as Deprecated, and have it call the new location one. Otherwise its going to be tricky with using the latest OMPL with MoveIt!. Proper tick-tocking would be nice.
Hi,
I am trying to control schunk PG70 gripper with MoveIt!. MoveIt! generally requires all dimensions to be in meters. I am currently using a package from [https://github.com/jlarraez/schunk_lwa4p] for PG70 integration. My PG70 is able to move only when i give a value in range 0.05 to 1.14 and it is an unknown unit. From spec, i could understand that PG70 can move from 0-68 mm(millimeters) so the value which it should move with respect to moveit is 0.00 to 0.068 meters. Now the package which i use is not moving the gripper at that required range instead it moves only for 0.05 to 1.14.
Anyone please suggest me a way to move my gripper at its actual physical unit?
Thanks in advance.
Perhaps merge OMPLInterface and OMPLInterfaceROS classes?
That should make for some simplified code.
I was trying to benchmark the RRT* algorithm from MoveIt and I encountered a segfault when the planner is being setup by the context manager.
Maybe we should check if pdef_ exists in setup(), and if not, put setup_ back to false so that requires planner needs to be setup again.
Maybe this should be in OMPL instead of MoveIt, actually... thoughts?
When following the directions :
Press the "Set Start To Current" button in the "Planning" tab at the bottom of the Motion Planning plugin. This will set the start configuration that you want to plan from to the current configuration of the robot. You will need to do this every time when planning with a real or simulated robot.
It appears this button sets the start position to the initial position of the robot, not its current position. So that after the first plan is executed, the initial position no longer matches the current position, and the button does not operate as expected.
When solve() is called with count > max_planning_threads_ termination occurs after number of successful plans = max_planning_threads_ because the the OMPL library calls the terminate() function of the planning termination condition when that number is reached. Therefore, subsequent calls to solve() return without creating new plans.
Looks like something funky is going on in the bloom config -- need to dig into it. There may also be missing depends -- I haven't been able to get that far yet.
Since 6b6dca1 ,the ompl plugin fails to load for my robot setup generated with the setup assistant. Using the groovy-devel branch, some breakage is probably expected, but I figured filing a ticket can't hurt, in case issue was overlooked.
'planning_models' is from the old arm-navigation stack and is mentioned as depreciated on the ros pages.
Supposedly the functionality has been ported to moveit but I cannot find the equivalent for the RobotState conversions?
I am migrating from groovy to hydro, and as our existing code uses sbpl I get this error when compiling moveit_planners;
[rospack] Error: package/stack 'sbpl_interface' depends on non-existent package 'planning_models' and rosdep claims that it is not a system dependency. Check the ROS_PACKAGE_PATH or try calling 'rosdep update'
Am I missing something here? Should I just use the arm-navigation groovy branch?
Hello,
This not so much an issue as a question, so I'm sorry if I'm asking this in a wrong place.
OK, so I've been playing around with OMPL and I've implemented a modification of RRT* algorithm. Now I'm wondering is there a way to make this algorithm visible to Moveit! package. Just a week or two weeks ago I was able to do this. This is what I've done:
added this line:
registerPlannerAllocator("geometric::MyPlanner", boost::bind(&allocatePlannerog::MyPlanner, _1, _2, _3));
to the method "ompl_interface::PlanningContextManager::registerDefaultPlanners()"
Today I tried doing the exact same thing but it's not working anymore :( I'm guessing something changed in a past few weeks with Moveit! package.
Thank you for your help in advance :-)
Branimir
The TRRT planner from OMPL crashes move_group with an invalid pointer dereference:
[ INFO] [1448231583.542524841]: Planner configuration 'arm[TRRTkConfigDefault]' will use planner 'geometric::TRRT'. Additional configuration parameters will be set when the planner is constructed.
move_group: /usr/include/boost/smart_ptr/shared_ptr.hpp:653: typename boost::detail::sp_member_access<T>::type boost::shared_ptr<T>::operator->() const [with T = ompl::base::ProblemDefinition; typename boost::detail::sp_member_access<T>::type = ompl::base::ProblemDefinition*]: Assertion `px != 0' failed.
partial backtrace:
#4 0x00007fbacbaf7ffc in ?? () from /opt/ros/indigo/lib/x86_64-linux-gnu/libompl.so.10
#5 0x00007fbacbb9a6a9 in ompl::geometric::TRRT::setup() () from /opt/ros/indigo/lib/x86_64-linux-gnu/libompl.so.10
The include order for OMPL and catkin in ompl/CMakeLists.txt seems wrong to me. However, there are already two commits switching this around: 329fb63 and b888117, so making another pull request without discussion does not make sense.
The question is basically if catkin_INCLUDE_DIRS or OMPL_INCLUDE_DIRS should be preferred. I believe OMPL_INCLUDE_DIRS should be preferred. Otherwise, when working with a source build OMPL on a standard ROS install, which includes the released OMPL, this will shadow the source build OMPL.
In contrast 329fb63 states that this prevents ROS package shadowing. Shouldn't that still work as either OMPL_INCLUDE_DIRS is not set or should be set to the lowest overlay?
In either case, the order of link_directories should probably match the include order.
When compiling moveit_planners with the latest OMPL I get the error:
/home/dave/ros/ws_moveit/src/moveit_planners/ompl/ompl_interface/src/parameterization/joint_space/joint_model_state_space_factory.cpp: In member function ‘virtual ompl_interface::ModelBasedStateSpacePtr ompl_interface::JointModelStateSpaceFactory::allocStateSpace(const ompl_interface::ModelBasedStateSpaceSpecificati\
on&) const’:
/home/dave/ros/ws_moveit/src/moveit_planners/ompl/ompl_interface/src/parameterization/joint_space/joint_model_state_space_factory.cpp:54:69: error: cannot allocate an object of abstract type ‘ompl_interface::JointModelStateSpace’
/home/dave/ros/ws_moveit/src/moveit_planners/ompl/ompl_interface/include/moveit/ompl_interface/parameterization/joint_space/joint_model_state_space.h:45:7: note: because the following virtual functions are pure within ‘ompl_interface::JointModelStateSpace’:
/home/dave/ros/ws_ompl/devel/include/ompl/base/StateSpace.h:283:28: note: virtual double ompl::base::StateSpace::getMeasure() const
/home/dave/ros/ws_moveit/src/moveit_planners/ompl/ompl_interface/src/parameterization/work_space/pose_model_state_space_factory.cpp: In member function ‘virtual ompl_interface::ModelBasedStateSpacePtr ompl_interface::PoseModelStateSpaceFactory::allocStateSpace(const ompl_interface::ModelBasedStateSpaceSpecification&\
) const’:
/home/dave/ros/ws_moveit/src/moveit_planners/ompl/ompl_interface/src/parameterization/work_space/pose_model_state_space_factory.cpp:87:68: error: cannot allocate an object of abstract type ‘ompl_interface::PoseModelStateSpace’
/home/dave/ros/ws_moveit/src/moveit_planners/ompl/ompl_interface/include/moveit/ompl_interface/parameterization/work_space/pose_model_state_space.h:46:7: note: because the following virtual functions are pure within ‘ompl_interface::PoseModelStateSpace’:
/home/dave/ros/ws_ompl/devel/include/ompl/base/StateSpace.h:283:28: note: virtual double ompl::base::StateSpace::getMeasure() const
And to fix it I had to revert this commit from OMPL for last week:
ompl/ompl@b947515
I'm not sure what the proper approach is to fix this @mamoll @isucan
Thanks!
Parallel issue in OMPL
https://bitbucket.org/ompl/ompl/issue/92/rrtconnect-with-6dof-pose-goal-in-30s
I'm running RRTconnect through MoveIt on the PR2 and I provided it with a 6DOF goal pose and a 30 second planning time.
However the planner returns, stating failure to sample any valid states from the goal tree after 2 seconds.
Shouldn't it keep trying to sample a goal state for 30 seconds?
The inheritance hierarchy in OMPL and MoveIt for this is as follows.
ompl_interface::ConstrainedGoalSampler
ompl::base::GoalLazySamples
ompl::base::GoalStates
ompl::base::GoalSampleableRegion
ompl::base::GoalRegion
ompl::base::Goal
GoalSampleableRegion has 3 virtual methods:
For GoalStates:
For GoalLazySamples:
For ConstrainedGoalSampler:
Here is the part where the planner essentially blocks until a goal sample is available:
ob::PlannerInputStates::nextGoal(const PlannerTerminationCondition &ptc) line 268
Here goal is pointing to a ConstrainedGoalSampler instance.
You can see it makes a call to GoalSampleableRegion::maxSampleCount(), which calls GoalStates::maxSampleCount() which returns states_.size()
This is zero because no valid states have been sampled yet.
Additionally GoalSampleableRegion::canSample() resolves to GoalSampleableRegion::canSample(), which returns the result of maxSampleCount() > 0
Which also is false.
As a result of this Line 290 in Planner.cpp is never true.
I'm not sure if this is the reason why the planner exits early though...
Perhaps the fix here is to add the virtual methods to ompl::base::GoalLazySamples and implement them in ompl_interface::ConstrainedGoalSampler ?
You can replicate this by uncommenting the path_constraints line in pr2_moveit_tutorials/planning/src/motion_planning_interface_tutorial.cpp, compliling and then running:
roslaunch pr2_moveit_tutorials motion_planning_interface_tutorial.launch
Here's the relevant backtrace:
#0 0x00007ffff4fbb425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x00007ffff4fbeb8b in __GI_abort () at abort.c:91
#2 0x00007ffff561169d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00007ffff560f846 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4 0x00007ffff560f873 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x00007ffff560f96e in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00007fffde1e6875 in ompl::base::StateSpace::setup() () from /opt/ros/groovy/lib/libompl.so.6
#7 0x00007fffde1e6994 in ompl::base::CompoundStateSpace::setup() () from /opt/ros/groovy/lib/libompl.so.6
#8 0x00007fffde1e6994 in ompl::base::CompoundStateSpace::setup() () from /opt/ros/groovy/lib/libompl.so.6
#9 0x00007fffde1efb29 in ompl::base::SpaceInformation::setup() () from /opt/ros/groovy/lib/libompl.so.6
#10 0x00007fffde28fb02 in ompl::geometric::SimpleSetup::setup() () from /opt/ros/groovy/lib/libompl.so.6
#11 0x00007fffde601a4d in ompl_interface::ModelBasedPlanningContext::configure() () from /wg/stor2a/sachinc/code-new/moveit_local/devel/lib/libmoveit_ompl_interface.so
#12 0x00007fffde5d4115 in ompl_interface::OMPLInterface::prepareForSolve(moveit_msgs::MotionPlanRequest_<std::allocator<void> > const&, boost::shared_ptr<planning_scene::PlanningScene const> const&, moveit_msgs::MoveItErrorCodes_<std::allocator<void> >*, unsigned int*, double*) const () from /wg/stor2a/sachinc/code-new/moveit_local/devel/lib/libmoveit_ompl_interface.so
#13 0x00007fffde5d531a in ompl_interface::OMPLInterface::solve(boost::shared_ptr<planning_scene::PlanningScene const> const&, moveit_msgs::MotionPlanRequest_<std::allocator<void> > const&, planning_interface::MotionPlanResponse&) const ()
from /wg/stor2a/sachinc/code-new/moveit_local/devel/lib/libmoveit_ompl_interface.so
#14 0x00007fffdea7b430 in ompl_interface_ros::OMPLPlanner::solve(boost::shared_ptr<planning_scene::PlanningScene const> const&, moveit_msgs::MotionPlanRequest_<std::allocator<void> > const&, planning_interface::MotionPlanResponse&) const ()
from /wg/stor2a/sachinc/code-new/moveit_local/devel/lib/libmoveit_ompl_planner_plugin.so
#15 0x00000000004622b2 in main ()
It would be nice to be able to set the OptimizingObjective when using ompl-based planing. Currently my robot arm does some pretty wild movements at times and optimizing for mechanical work might give better results?
This ticket is simply to let folks know that I'm working on this (err, I have been working on this for far too long already.....) in conjunction with the guys at the SBPL lab. The updated interface should provide significant improvements to available motion primitives. I hope to have a PR ready shortly after the new year.
I've recently released SBPL into Indigo, and current work on the plugin is going on in my sandbox: https://github.com/mikeferguson/sandbox/tree/hydro-devel/sbpl_interface. The final code/API will depend on ros-planning/moveit_core#215
Hi,
When i am trying to execute a goal in MoveIt, i could see MoveIt resulting in longer trajectories most of the time.
Without MoveIt in picture, I am able to execute shortest trajectory by giving only the shortest path computed (i.e. only goal joints positions) to actionClient "/arm/joint_trajectory_controller/follow_joint_trajectory" using actionlib.
I am trying to do the same using MoveIt.
I also tried by giving the computed shortest path (goal joint position) using below code, but unexpectedly MoveIt again is planning a trajectory(set of points-path) for the same and it resulted in long trajectories again.
group_variable_values = group.get_current_joint_values()
group_variable_values[0] = -1.57
group_variable_values[1] = 1.0
group_variable_values[2] = 0.35
group_variable_values[3] = 0.567
group_variable_values[4] = 0.0
group_variable_values[5] = 2.2
group.set_joint_value_target(group_variable_values)
group.go(wait=True)
So can any one help me in finding and providing shortest trajectory for goal execution using MoveIt.
Thanks in advance.
I launch move_group in one window, then launch Rviz with the Motion Planning Plugin already configured in the config file. As soon as Rviz finishes launch move_group crashes. I've backtraced the segfault (below) to the ompl_plugin.cpp call getPlanningAlgorithms(). It crashes when looping through pconfig, which is of type std::map<std::string, ompl_interface::PlanningConfigurationSettings>. For some reason the planning context manager is not returning a valid map... it appears setPlanningConfigurations() in planning_context_manager.cpp is never called.
GDB Backtrace:
INFO ros.moveit_ros_planning: Trajectory execution is managing controllers
[New Thread 0x7fffbb4d7700 (LWP 19533)]
[New Thread 0x7fffbacd6700 (LWP 19542)]
[New Thread 0x7fffba4d5700 (LWP 19551)]
INFO ros.moveit_ros_move_group: MoveGroup running using planning plugin ompl_interface/OMPLPlanner
---Type <return> to continue, or q <return> to quit---
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffde94a700 (LWP 19312)]
0x00007fffd45a198d in ompl_interface::OMPLPlanner::getPlanningAlgorithms(std::vector<std::string, std::allocator<std::string> >&) const () from /home/dave/ros/moveit/devel/lib/libmoveit_ompl_planner_plugin.so
(gdb) bt
#0 0x00007fffd45a198d in ompl_interface::OMPLPlanner::getPlanningAlgorithms(std::vector<std::string, std::allocator<std::string> >&) const () from /home/dave/ros/moveit/devel/lib/libmoveit_ompl_planner_plugin.so
#1 0x00000000004d52fa in move_group::MoveGroupQueryPlannersService::queryInterface(moveit_msgs::QueryPlannerInterfacesRequest_<std::allocator<void> >&, moveit_msgs::QueryPlannerInterfacesResponse_<std::allocator<void> >&) ()
#2 0x00000000004d6eae in ros::ServiceCallbackHelperT<ros::ServiceSpec<moveit_msgs::QueryPlannerInterfacesRequest_<std::allocator<void> >, moveit_msgs::QueryPlannerInterfacesResponse_<std::allocator<void> > > >::call(ros::ServiceCallbackHelperCallParams&) ()
#3 0x00007ffff5cd9c28 in ros::ServiceCallback::call() () from /opt/ros/groovy/lib/libroscpp.so
#4 0x00007ffff5d178e9 in ros::CallbackQueue::callOneCB(ros::CallbackQueue::TLS*) ()
from /opt/ros/groovy/lib/libroscpp.so
#5 0x00007ffff5d1938b in ros::CallbackQueue::callAvailable(ros::WallDuration) ()
from /opt/ros/groovy/lib/libroscpp.so
---Type <return> to continue, or q <return> to quit---
#6 0x00007ffff5d681c6 in ros::AsyncSpinnerImpl::threadFunc() () from /opt/ros/groovy/lib/libroscpp.so
#7 0x00007ffff6812ce9 in thread_proxy () from /usr/lib/libboost_thread.so.1.46.1
#8 0x00007ffff65f0e9a in start_thread (arg=0x7fffde94a700) at pthread_create.c:308
#9 0x00007ffff3e8dcbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#10 0x0000000000000000 in ?? ()
src/moveit_ros/move_group is the package moveit_ros_move_group
but
src/moveit_planners/ompl is the package moveit_ompl_planners
Seems like to me OMPL should be named moveit_planners_ompl
I know you just re-factored but I'm still getting used to a package folder not have the requirement of having the exact same name of the package itself. We should at least have consistent naming schemes so that developers can easily remember what a package and its location is...
The first naming scheme is what I have seen across almost all of MoveIt thus far...
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.