Giter Site home page Giter Site logo

moveit / moveit Goto Github PK

View Code? Open in Web Editor NEW
1.6K 1.6K 938.0 68.16 MB

:robot: The MoveIt motion planning framework

Home Page: http://moveit.ros.org

License: BSD 3-Clause "New" or "Revised" License

CMake 1.95% Python 3.41% C++ 94.15% C 0.03% Makefile 0.01% GDB 0.01% HTML 0.01% Shell 0.26% Dockerfile 0.07% NASL 0.03% TeX 0.09%

moveit's Introduction

MoveIt Logo

The MoveIt Motion Planning Framework for ROS. For the ROS 2 repository see MoveIt 2. For the commercially supported version see MoveIt Pro.

Easy-to-use open source robotics manipulation platform for developing commercial applications, prototyping designs, and benchmarking algorithms.

Branches Policy

  • We develop latest features on master.
  • The *-devel branches correspond to released and stable versions of MoveIt for specific distributions of ROS. noetic-devel is synced to master currently.
  • Bug fixes occasionally get backported to these released versions of MoveIt.
  • To facilitate compile-time switching, the patch version of MOVEIT_VERSION of a development branch will be incremented by 1 w.r.t. the package.xml's version number.

MoveIt Status

Continuous Integration

service Melodic Master
GitHub Format CI Format CI
CodeCov codecov codecov
build farm Build Status Build Status
Docker
Pulls
automated build docker

Licenses

FOSSA Status

ROS Buildfarm

MoveIt Package Melodic Source Melodic Debian Noetic Source Noetic Debian
moveit Build Status Build Status Build Status Build Status
moveit_core Build Status Build Status Build Status Build Status
moveit_kinematics Build Status Build Status Build Status Build Status
moveit_planners Build Status Build Status Build Status Build Status
moveit_planners_ompl Build Status Build Status Build Status Build Status
moveit_planners_chomp Build Status Build Status Build Status Build Status
chomp_motion_planner Build Status Build Status Build Status Build Status
moveit_chomp_optimizer_adapter Build Status Build Status Build Status Build Status
pilz_industrial_motion_planner Build Status Build Status Build Status Build Status
pilz_industrial_motion_planner_testutils Build Status Build Status Build Status Build Status
moveit_plugins Build Status Build Status Build Status Build Status
moveit_fake_controller_manager Build Status Build Status Build Status Build Status
moveit_simple_controller_manager Build Status Build Status Build Status Build Status
moveit_ros_control_interface Build Status Build Status Build Status Build Status
moveit_ros Build Status Build Status Build Status Build Status
moveit_ros_planning Build Status Build Status Build Status Build Status
moveit_ros_move_group Build Status Build Status Build Status Build Status
moveit_ros_planning_interface Build Status Build Status Build Status Build Status
moveit_ros_benchmarks Build Status Build Status Build Status Build Status
moveit_ros_perception Build Status Build Status Build Status Build Status
moveit_ros_occupancy_map_monitor Build Status Build Status Build Status Build Status
moveit_ros_manipulation Build Status Build Status Build Status Build Status
moveit_ros_robot_interaction Build Status Build Status Build Status Build Status
moveit_ros_visualization Build Status Build Status Build Status Build Status
moveit_ros_warehouse Build Status Build Status Build Status Build Status
moveit_servo Build Status Build Status Build Status Build Status
moveit_runtime Build Status Build Status Build Status Build Status
moveit_commander Build Status Build Status Build Status Build Status
moveit_setup_assistant Build Status Build Status Build Status Build Status
moveit_msgs Build Status Build Status Build Status Build Status
geometric_shapes Build Status Build Status Build Status Build Status
srdfdom Build Status Build Status Build Status Build Status
moveit_visual_tools Build Status Build Status Build Status Build Status
moveit_tutorials Build Status Build Status

Stargazers over time

Stargazers over time

moveit's People

Contributors

130s avatar adampettinger avatar andyze avatar bmagyar avatar brycestevenwilley avatar davetcoleman avatar de-vri-es avatar dg-shadow avatar felixvd avatar gavanderhoorn avatar henningkayser avatar hersh avatar isucan avatar j-petit avatar jafarabdi avatar jrgnicho avatar jspricke avatar julienking avatar marioprats avatar mathias-luedtke avatar mayman99 avatar mikeferguson avatar mintar avatar mlautman avatar rhaschke avatar sachinchitta avatar simonschmeisser avatar tylerjw avatar v4hn avatar velveteenrobot avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

moveit's Issues

Consolidate moveit tutorials and other sphynx documentation

Currently our non-moveit website documentation lacks a common navigation side bar or central location for finding it. This makes understanding how documentation works, where stuff belongs, etc difficult.

I've consolidated all of the *.rst sprinkled across the moveit repo and moveit_pr2 and updated the theme. Note I have not spent the time fixing inline code or images yet because this is just a proposal (I did have to change some of the navigation though) and there are a few other small bugs:

I've put it in the already existing repo moveit_docs. I've also switched the page theme to mimick readthedocs.org, similar to how @wjwwood setup catkin_tools and how @mikeferguson setup the Fetch documentation. This issue is also explained here: #11

Advantages:

  • Easier to navigate between pages for users
  • Easier to add to and update for contributors
  • Centralized theme that looks good
  • Edit on Github button
  • Can provide more streamlined experience than having docs in separate pkgs

Disadvantages

  • Docs are not inline with each package

The one question I'm trying to decide on is where the new moveit_docs folder should go. I think within our new moveit repo is best, but keeping it in a separate repo has advantages:

Advantages of adding it to moveit repo:

  • Will basically still be inline with code, so API changes can be propagated easier with grep commands, etc
  • Can request all new features to include in the same PR an update to the docs
  • Can easily track changes in API across different ROS versions with our pre-existing -devel branches
  • This is how the ompl project does it and many others

Disadvantages of adding it to the moveit repo:

  • We might not want to include images in the main repo for file size reasons. If this is the case, we could keep them in moveit_resources as assets but takes a little more work. We don't have that many GUIs/images though, so this is likely minimum effort
  • This is how fetch does it

This consolidation would greatly ease user's abilities to improve documentation on World MoveIt! Day, so that is my target date to finish

Create an overview page over plugin mechanism

MoveIt has quite a number of plugin mechanisms.
They should be the primary interface for new work in a number of sub-fields handled by MoveIt,
but we are missing documentation on them.
These are (In no particular order):

  • move_group::MoveGroupCapability
  • occupancy_map_monitor::OccupancyMapUpdater
  • planning_request_adapter::PlanningRequestAdapter
  • kinematics::KinematicsBase
  • planning_interface::Planner
  • planning_interface::PlannerManager
  • moveit_controller_manager::MoveItControllerManager
  • moveit_ros_control_interface::ControllerHandleAllocator
  • moveit_sensor_manager::MoveItSensorManager
  • constraint_samplers::ConstraintSamplerAllocator
  • collision_detection::CollisionPlugin

and in kinetic-devel also

  • warehouse_ros::DatabaseConnection

Some of them are mentioned in passing on http://moveit.ros.org/documentation/concepts/ ,
but most are not explained anywhere except for their class definition in the code.
It would be great to have a web page "Plugin interfaces" in the "Documentation" tab on moveit.ros.org with a short block of documentation on each of them:

  • What is it used for?
  • What can I achieve by implementing a plugin of that type?
  • What does the resp. plugin interface look like (including a link to the base class header)
  • Where can an example implementation be found?

This involves quite a bit of code research on the interfaces and is obviously too much for one person to do, so the idea is that you can just add a note here saying which plugin you wish to document and file a pull request against https://github.com/ros-planning/moveit.ros.org 's request-plugins-explained branch explaining the plugin here.

Improve MoveIt! Quick Start guide

Would like to expand upon our current Rviz Motion Planning plugin tutorial with the PR2 to make it streamlined for new users:

  • Improve ordering of tutorials so that they are cohesive for new users
  • Should new users first learn the PR2 with Setup Assistant or do we want them to be able to immediatly plan in Rviz with the PR2?
  • There are some broken links

There is now a link at the button of the install page for the Quick Start

move_group segfaults after multiple planning requests

I have a simple URDF for a robotic arm for which I generate a MoveIt setup.

Then I run the demo using

roslaunch [generated package] demo.launch debug:=true

From there, if I run several times [usually less than 20] "Plan & Execute" to a random valid state, I end up seeing the move_group process segfault.

Thanks to the debug:=true argument, I am able to see some details (on Kinetic):

[ INFO] [1470066134.494887876]: LBKPIECE1: Created 17 (8 start + 9 goal) states in 13 cells (7 start (7 on boundary) + 6 goal (6 on boundary))
[ INFO] [1470066134.496745447]: LBKPIECE1: Created 45 (19 start + 26 goal) states in 35 cells (18 start (18 on boundary) + 17 goal (17 on boundary))
[ INFO] [1470066134.498151876]: LBKPIECE1: Created 85 (39 start + 46 goal) states in 72 cells (37 start (37 on boundary) + 35 goal (35 on boundary))
[Thread 0x7fffb5d62700 (LWP 13802) exited]
[Thread 0x7fffb5561700 (LWP 13801) exited]
[Thread 0x7fffb4d60700 (LWP 13800) exited]

Thread 41 "move_group" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffa7fff700 (LWP 13799)]
0x00007fffc95a99ad in ompl::Grid<ompl::geometric::Discretization<ompl::geometric::LBKPIECE1::Motion>::CellData*>::neighbors(std::vector<int, std::allocator<int> >&, std::vector<ompl::Grid<ompl::geometric::Discretization<ompl::geometric::LBKPIECE1::Motion>::CellData*>::Cell*, std::allocator<ompl::Grid<ompl::geometric::Discretization<ompl::geometric::LBKPIECE1::Motion>::CellData*>::Cell*> >&) const () from /opt/ros/kinetic/lib/x86_64-linux-gnu/libompl.so.12
(gdb) 

I could reproduce this crash on both Kinetic (built from sources) but also Indigo (using Docker).

I'm open to suggestions on how to investigate this further. I'll try to record the requests, and see if the move_group crash is always reproducible with a particular request. I also need to run with debug on on Indigo to compare the error messages.

Also, perhaps this isn't the best repo for this issue: I'll recreate it where appropriate once the root cause is identified.

database_grasp_planning service with moveit_msgs/Grasp.msg

MoveIt's PickPlace pipeline supports using external ros-services for Grasp-Planning.
This feature can be used to pick objects from client code via move_group_interface->pick("objectname").
In this case the Pick action server invokes the external service database_grasp_planning (that the user has to implement and start beforehand) to compute possible grasps.

The problem is that this service adheres to the specification manipulation_msgs/GraspPlanning.srv. This specification uses the package's version of the Grasp.msg which has been reworked since and is now provided in moveit_msgs/Grasp.msg. The manipulation_msgs package is deprecated.
As a result, all grasps returned by the service have to be copied field-by-field and some fields are even missing.
This makes it impossible to provide time information for the gripper motions during the pick and it makes it impossible to specify the post_grasp_retreat direction of the grasp when using the service interface.

To fix this, the service specification should be copied to moveit_msgs and adapted to use moveit_msgs/Grasp. This will probably add a number of other messages too.
A service client for the new ROS-service should be added next to the existing one. It should connect to a service named plan_grasps (to avoid name collisions).

In indigo-devel and jade-devel the old service should still be called if the new service does not exist, in kinetic-devel, the old service can be removed entirely to simplify the manipulation code.

We might want to discuss the exact shape of moveit_msgs/GraspPlanning.srv before merging this upstream, but a full implementation that only has to be refined afterwards is definitely possible in one day of work.

Cleanup old HTML in markdown-based website

The MoveIt! website was migrated from a Wordpress site, and much of the formatting is still in HTML blocks that are not ideally formatted. We would like to convert this information to cleaner markdown, and move images to the proper locations. For example the install page.

Move existing IK tests

@jrgnicho did a great job of creating KinematicsBase tests, but they have not been integrated into the main MoveIt! project and they are not run by travis. We would like to pull this whole repo into the main moveit codebase and have them triggered by travis/catkin every time

Things to consider:

  • Do we need to import both robots or can we base them on the PR2 or Fanuc robots?
  • The URDFs should probably be moved to moveit_resources
  • How long do the tests take and how much output?
  • What is the overlap between these tests and the IK tests the PR2 already has in moveit?

Jade Release

@130s I think we need to release the jade packages again to bring in moveit/moveit_ros#699, right?

At that point, after the next ROS sync, I think we can consider jade released right? We'll want the new ros-jade-moveit metapackage. the moveit_pr2 packages will still not be available though moveit/moveit_pr2#71

@v4hn had called moveit/moveit_ros#728 a jade blocker but we've since reverted those changes, so I think it should be skipped for this release

I'm adding jade install instructions to the moveit website at the moment, with an experimental warning

[ros_robot_interaction] Fix warning

In the kinetic build there is currently a warning:

Warnings << moveit_ros_robot_interaction:make /root/ros/ws_moveit/logs/moveit_ros_robot_interaction/build.make.000.log
/root/ros/ws_moveit/src/moveit/moveit_ros/robot_interaction/src/interaction_handler.cpp: In member function โ€˜const kinematics::KinematicsQueryOptions& robot_interaction::InteractionHandler::getKinematicsQueryOptions() constโ€™:
/root/ros/ws_moveit/src/moveit/moveit_ros/robot_interaction/src/interaction_handler.cpp:614:75: warning: returning reference to temporary [-Wreturn-local-addr]
   return kinematic_options_map_->getOptions(KinematicOptionsMap::DEFAULT).options_;
                                                                           ^
cd /root/ros/ws_moveit/build/moveit_ros_robot_interaction; catkin build --get-env moveit_ros_robot_interaction | catkin env -si  /usr/bin/make --jobserver-fds=6,7 -j; cd -

After fixing need to ensure interactive markers still work with MoveIt! in Rviz

Consolidate kinematics plugins into one folder, including ikfast

Per @v4hn recently:

Personally, I don't understand why the other kinematics plugins are in there and wouldn't moveit_ikfast in there either...
In my opinion it would make more sense to create a new top-level-folder/package moveit_kinematics_plugins in the repo and make it part of the meta-package. This should even be possible without breaking anything, because the plugin-descriptions do not reference the package name and the only way the plugins are used is through their plugin descriptions.

Moving ikfast into a new package would also fix a versioning problem we're having (discussion) because currently its too high (v3 instead of ~v0.7.x)

I'm proposing someone create a moveit_kinematics package in this repo that removes the solvers from moveit_ros/planners

rename planning_interface::MoveGroup to planning_interface::MoveGroupInterface

An often observed source of confusion in MoveIt is the class "MoveGroup".

While everyone instantly believes to recognize this as the node that encapsulates most of MoveIt's functionality in ROS, this class actually lives in "planning_interface" and only provides a client interface to interact with the node via ROS-interfaces. It is often believed that most of the class methods call library functions and do not wrap ROS interfaces.

As such it should be renamed "MoveGroupInterface" in kinetic. This includes a number of steps (in order)

  • move move_group.h to move_group_interface.h and rename the class
  • provide a new move_group.h that provides a typedef named MoveGroup to be downward compatible
  • rename the class throughout MoveIt's own code base
  • adjust the tutorials to the new name
  • add a deprecation notice to move_group.h

Cartesian Coordinate Planning

Hello,
I want to use an kuka kr6 robot for a pick and place task. The coordinates come in Cartesian coordinates. All I want to do is write a little application that connects theses coordinates via paths that I want to create with MoveIt and sends that path to the real robot afterwards. Therefore I want to use the Move Group Interface with Python. I tried to use the pr_2 moveit documentation (http://docs.ros.org/hydro/api/pr2_moveit_tutorials/html/planning/scripts/doc/move_group_python_interface_tutorial.html) and make it work with the kuka instead.
My first attempt is just to have a working Python script that I can change afterwards.

cube_move_launch.txt
cube_move_py.txt

I put the launch file into the launch folder within the kr6 moveit config folder from the github kuka_experimental package and the python script is the moveit config folder (with config, launch etc.)
When I try to run the script I get :

InvalidPackage: Invalid package manifest "/home/zema-4by3/catkin_ws_kr6/src/kuka_experimental-kr6r900sixx_moveit_rsi_convenience/kuka_resources/package.xml": The manifest contains invalid XML:
maximum recursion depth exceeded while calling a Python object.

My first issue here is that the package.xml found is different from the one that should be used. Is there a way to force catkin to search a defined path for the package.xml?
My second issue will be that I don't know how to send the path information created from RViz to the actual robot. Do I have to subscribe to a topic to accomplish that?
Thank you for your help.

cleanup move_group namespace

The move action server's (providing planning and execution capabilities) and the dynamic reconfigure's topics of the move_group node, reside in the same namespace, making it hard to distinguish them (see list below). I suggest to rename the move action from move_group to move or plan.
Furthermore, I think it might be useful to group all move_group-provided stuff into its own namespace. However, this would break existing systems...

/move_group/cancel
/move_group/display_contacts
/move_group/display_cost_sources
/move_group/display_grasp_markers
/move_group/display_planned_path
/move_group/fake_controller_joint_states
/move_group/feedback
/move_group/goal
/move_group/monitored_planning_scene
/move_group/motion_plan_request
/move_group/ompl/parameter_descriptions
/move_group/ompl/parameter_updates
/move_group/plan_execution/parameter_descriptions
/move_group/plan_execution/parameter_updates
/move_group/planning_scene_monitor/parameter_descriptions
/move_group/planning_scene_monitor/parameter_updates
/move_group/result
/move_group/sense_for_plan/parameter_descriptions
/move_group/sense_for_plan/parameter_updates
/move_group/status
/move_group/trajectory_execution/parameter_descriptions
/move_group/trajectory_execution/parameter_updates

Number of states in OMPL planned trajectory not being reduced

I am working with a servo system that cannot accept new commands while one is already in progress. Due to this, I would prefer to have the minimum number of segments in my trajectory. As a test, I plan a simple path that just moves a prismatic joint .1 meters or so. This always results in a trajectory with 10 segments. It seems as if 10 is the minimum number of segments, any idea where this comes from?

It is an OMPL plan, I have tried several planners. It looks like it is being reduced to 2 states in Path Simplification, however, it then returns 10 states anyway. Here is a typical output (same issue in Indigo and Kinetic):

ros.ompl: LBKPIECE1: Starting planning with 1 states already in datastructure
ros.ompl: LBKPIECE1: Waiting for goal region samples ...
ros.ompl: Beginning sampling thread computation
ros.ompl: Stopped goal sampling thread after 10 sampling attempts
ros.ompl: LBKPIECE1: Waited 0.010119 seconds for the first goal sample.
ros.ompl: LBKPIECE1: Created 34 (18 start + 16 goal) states in 21 cells (15 start (15 on boundary) + 6 goal (6 on boundary))
ros.ompl: Solution found in 0.022833 seconds
ros.rosconsole_bridge.urdfdom: There were 17 valid motions and 8 invalid motions.
ros.ompl: SimpleSetup: Path simplification took 0.000118 seconds and changed from 11 to 2 states
ros.rosconsole_bridge.urdfdom: Returning successful solution with 10 states
ros.moveit_ros_planning: Running 'Add Time Parameterization'
ros.moveit_ros_planning: Motion planner reported a solution path with 10 states
ros.moveit_ros_planning: Planned path was found to be valid when rechecked
ros.moveit_ros_move_group.actionlib: Setting the current goal as succeeded
ros.moveit_ros_move_group.actionlib: Setting status to succeeded on goal, id: /rviz_matt_Laptop_28419_3325375262905671775-1-1470320715.943876096, stamp: 1470320715.94
ros.moveit_ros_move_group.actionlib: Publishing result for goal with id: /rviz_matt_Laptop_28419_3325375262905671775-1-1470320715.943876096 and stamp: 1470320715.94
ros.moveit_ros_move_group.actionlib: Publishing feedback for goal, id: /rviz_matt_Laptop_28419_3325375262905671775-1-1470320715.943876096, stamp: 1470320715.94
ros.moveit_ros_move_group.actionlib: Publishing feedback for goal with id: /rviz_matt_Laptop_28419_3325375262905671775-1-1470320715.943876096 and stamp: 1470320715.94

Can't launch demo.launch with db:=true

I'm trying to connect to the warehouse, and in jade and kinetic I'm not able to do so. warehouse_ros does not seem to contain the mongo_wrapper_ros.py which is listed in the launch file here.

Is anyone else using the warehouse?

Integrate Fermi GUIs into moveit

Original topic: ros-industrial-consortium/fermi#26

@rkojcev has done a great job of adding a new method for using MoveIt! via a GUI with interactive markers. Perhaps we want to merge this functionality into moveit

screenshot from 2016-08-07 14 27 24

  • Have outside developer check that Fermi is documented enough to be robot agnostic
  • Open PR against main moveit repo so we can start review

C++11ifying the public API for the kinetic release

So, there has been some discussion about C++11ifying the moveit API. It would make sense to do that for the Kinetic release, or we're stuck with the old API for another 4 years until the next long-term support platform.

As far as I can see, C++11ifying the API basically comes down mainly to replacing boost types with the equivalent std types from C++11. From the top of my head the most likely changes here would be:

  • Switch from boost to C++11 smart pointer.
  • Switch from boost::function to std::function
  • Switch from boost::chrono types to std::chrono types.
  • Switch from boost synchronisation types to C++11 equivalents (std::mutex and friends)
  • Possibly use std::tuple instead of boost equivalents (probably not needed)
  • Use enum class instead of old enums.

There are some more changes possible which are unlikely to affect the public API:

  • Switch from boost to std::bind
  • Switch from boost to std::thread
  • Use the new random number generator facilities
  • Simplify things internally using C++11 features (lambdas, range based for loops, etc...)

Some shared_ptr types will be forced by the ROS API, but those are generally used through typedefs like sensor_msgs::JointStatePtr. Those would be left alone of course.

@davetcoleman also suggested seeing what clang-tidy comes up with, which seems like a good idea.

So, I would like to undertake a project like this on the short term (on time for Kinetic which shouldn't be delayed too long I think). But before doing anything like that of course I'd like to know what other people think about C++11ifying the API.

Kinetic Release

Discussion moved from old repo: moveit/moveit_ros#695

Discuss here issues related to releasing Kinetic. We can track remaining issues in this new milestone: https://github.com/ros-planning/moveit/milestone/1

I don't think we can add milestones for issues in other repos. Creating that list here:

make MoveIt's RViz display properly resizable

One of the most annoying everyday MoveIt issues many people experience is that the motion_planning display in RViz has a huge minimal size.
While everyone using RViz in fullscreen mode on a 24'' monitor does not notice this problem,
this can be a serious annoyance when working on a laptop screen.
This can likely be changed by placing either the QTabWidget or all subwidgets in 2D scrollable Qt Widget.

Params for trajectory execution are not correctly set currently?

For ros-industrial/fanuc_experimental#24

Using moveit_setup_assistant templates, parameters allowed_execution_duration_scaling and allowed_goal_duration_margin is set for move_group in trajectory_execution.launch.xml:
https://github.com/ros-planning/moveit/blob/7a3057a68927dfcc9bf2336c794597917cb9d2a6/moveit_setup_assistant/templates/moveit_config_pkg_template/launch/trajectory_execution.launch.xml#L9-L12

It is included in move_group.launch with namespace move_group:
https://github.com/ros-planning/moveit/blob/7a3057a68927dfcc9bf2336c794597917cb9d2a6/moveit_setup_assistant/templates/moveit_config_pkg_template/launch/move_group.launch#L28-L37

However, in rqt_reconfigure, the parameters seems being not set correctly as below and correct namespace looks /move_group/trajectory not /move_group:
image
As the figure shows, the parameters <param name="allowed_execution_duration_scaling" value="1.2"/> and <param name="allowed_goal_duration_margin" value="0.5"/> is not set.

I provided a patch for this: https://github.com/ros-industrial/fanuc_experimental/pull/24/files, but not sure if this is the correct solution.
Any ideas?

Consolidate moveit_resources for integration tests

According to the discussion in moveit/moveit_ros#729, we should:

  • Rename test folder in moveit_resources to pr2
  • Add a simple robot arm (e.g. test_robot alias Fanuc), including a moveit_config, for testing
  • Add integration tests in moveit_ros/test

The existing PR stuff is used in several locations:

./moveit_core/robot_state/test/test_kinematic_complex.cpp
./moveit_core/kinematic_constraints/test/test_constraints.cpp
./moveit_core/planning_scene/test/test_planning_scene.cpp
./moveit_core/constraint_samplers/test/test_constraint_samplers.cpp
./moveit_core/collision_detection_fcl/test/test_fcl_collision_detection.cpp
./moveit_core/robot_model/test/test.cpp

UPDATE:

Opened PRs

moveit_setup_assistant should require author details

catkin requires a maintainer and mail address to be specified in each package.xml.
Up to now the setup assistant does not ask for that information during setup, but just adds "[email protected]" there. This is clearly wrong and people forget to change that value later on.
An issue for this was filed here.

This commit implements basic support for configuration of the contact details in the GUI, but it is not yet ready for merging.

  • Check for valid mail address
  • Make sure the setup assistant can load the new parameters from a config already generated
  • Prohibit generation of the config when the contact details are not (yet) filled in

Integrating STOMP

Given the recent interest in STOMP and CHOMP planners I'll be working on adding stomp from industrial_moveit as another MoveIt planner. The current plan is to copy all relevant packages from industrial_moveit into the moveit_planners directory however there are some challenges related to that

  • The industrial_collision_detection package is a dependency so should that go in moveit_planners too.
  • The stomp_test_support and stomp_test_kr210_moveit_config packages contain files and resources (meshes, urdfs, launch, yamls) that we use for our testing the stomp planner, should those be included too?
  • How to preserve as much of the commit history as possible? Should we?

Add continous FCL collision checking for speedup

MoveIt! currently only collision checks motions/segments/edges by discretizing the segment at some resolution into individual states that are then sent one-by-one to FCL. This is also how MoveIt! plans with OMPL. Switching to FCL's powerful continuous collision checking will likely result in an important speedup (CC is the slowest part of planning).

Currently there are unimplemented functions for this in MoveIt!

We probably want to use FCL's BroadPhaseContinuousCollisionManager

An example implementation is already in OMPLApp

Would be great to find someone to work on this

@Levi-Armstrong, @mamoll, @panjia1983, @jslee02

Build from source instructions do not work

Ubuntu 16.04, ROS Kinetic desktop full installed from ros-shadow-fixed:

victor@X301A1:~/libraries/catkin_workspace/src$ rosdep install --from-paths . --ignore-src --rosdistro kinetic
ERROR: the following packages/stacks could not have their rosdep keys resolved
to system dependencies:
moveit_core: Cannot locate rosdep definition for [fcl]
moveit_planners_ompl: Cannot locate rosdep definition for [ompl]
moveit_ros_manipulation: Cannot locate rosdep definition for [manipulation_msgs]
moveit_commander: No definition of [python-pyassimp] for OS version [xenial]
$  dpkg -l | grep ros-kinetic-desktop
ii  ros-kinetic-desktop                                         1.3.0-0xenial-20160724-151604-0700                          amd64        A metapackage to aggregate several packages.
ii  ros-kinetic-desktop-full                                    1.3.0-0xenial-20160724-172007-0700                          amd64        A metapackage to aggregate several packages.

[jade] Invalid metapackage upon catkin_prepare_release

Self-assigned so I'm not really asking for help so far, but if anyone has experienced before your advice is appreciated.

$ cd moveit && git checkout jade-devel
$ catkin_prepare_release 
Prepare the source repository for a release.
Repository type: git
Found packages: moveit_controller_manager_example, moveit_ros_control_interface, moveit_fake_controller_manager, moveit_ros_perception, moveit_ros_move_group, moveit_ikfast, moveit_setup_assistant, moveit_
ros_benchmarks_gui, moveit_plugins, moveit_ros_benchmarks, moveit_ros_warehouse, moveit_commander, moveit_ros_visualization, moveit_ros_planning_interface, moveit_ros_robot_interaction, moveit_ros_planning
, moveit_core, moveit_planners, moveit_ros_manipulation, moveit_ros, moveit_simple_controller_manager, moveit_planners_ompl, moveit
Invalid metapackage at path '/home/rospasta/cws_planning/src/ros-planning/moveit/moveit':
  Metapackage 'moveit': Invalid CMakeLists.txt
Expected:
<<<cmake_minimum_required(VERSION 2.8.3)
project(moveit)
find_package(catkin REQUIRED)
catkin_metapackage()>>>
Got:
<<<cmake_minimum_required(VERSION 2.8.3)
project(moveit)
find_package(catkin REQUIRED)
catkin_metapackage()
>>>

See requirements for metapackages: http://ros.org/reps/rep-0127.html#metapackage

I ran diff to see if the "expected" and "Got" values are different, but nothing was returned.

I've experienced before but forgot how I managed to solve this.

make PlanningSceneInterface add/remove CollisionObjects synchronously

I would very much like to adjust PlanningSceneInterface::{add/remove}CollisionObjects
to use the new ApplyPlanningScene service such that it performs synchronous updates to the planning scene.
This is what most users expect and it is not even documented in the tutorials that this is not the case.

At the moment these methods wrap simple publish calls whereas the other methods in this class query the move_group via services.

Thus, the current behavior is (1) inconsistent, (2) not documented, and (3) makes people add arbitrary long sleep calls after the function call.

However, ApplyPlanningScene is a MoveGroupCapability that has to be added manually in each projects move_group.launch and the PlanningSceneInterface has been around quite long.
Thus, simply changing the implementation would break many use-cases.
As a downward-compatible workaround I propose to check whether the service exists and either (1) call the detected service or (2) print an appropriate warning telling the user to enable ApplyPlanningScene in their move_group and afterward continue with the current publish.
With ROS-m,n, or o we could eventually remove the publish then.

Add coveralls testing coverage badge

The FCL project has this cool badge that indicates what percent of the project has unit tests:

screenshot from 2016-07-29 09 16 30

You can also set a minimum required coverage percent so that new pull requests require unit tests be written for significant pieces of new code. Turning on this feature is a future topic

We would like to add coveralls support in MoveIt! - it does not look too complicated. The discussion and an example on how to do this can be found here

Execution of Cartesian Path Fails Due to Differing Current and Start State

To Whom It May Concern,

I'm using the code below to demonstrate sealing a window using Moveit's python interface. When I test it on both Clearpath Robotics' Husky with UR5 and Fetch Robotics' Fetch, I get either an error or erratic behavior that appears to be due to current pose and the start_pose not matching. However, they are set one after each other.

When the code is run on the UR5, the UR5 driver, Thomas Tim's ur_modern_driver ( https://github.com/ThomasTimm/ur_modern_driver), produces the following error.

[ERROR] [1470606513.263462897]: Goal start doesn't match current pose

However, this appears to occur every other trajectory. The Moveit! terminal output is included below.

[ INFO] [1470606478.642762190]: Combined planning and execution request received for MoveGroup action. Forwarding to planning and execution pipeline.
[ INFO] [1470606478.642964878]: Planning attempt 1 of at most 5
[ INFO] [1470606478.651951898]: No planner specified. Using default.
[ INFO] [1470606478.655162522]: RRTConnect: Starting planning with 1 states already in datastructure
[ INFO] [1470606478.672401766]: RRTConnect: Created 5 states (2 start + 3 goal)
[ INFO] [1470606478.672509679]: Solution found in 0.017943 seconds
[ INFO] [1470606478.684172456]: SimpleSetup: Path simplification took 0.011350 seconds and changed from 4 to 2 states
[ INFO] [1470606502.709724240]: Planning request received for MoveGroup action. Forwarding to planning pipeline.
[ INFO] [1470606502.710689320]: RRTConnect: Starting planning with 1 states already in datastructure
[ INFO] [1470606502.780919741]: RRTConnect: Created 4 states (2 start + 2 goal)
[ INFO] [1470606502.780984621]: Solution found in 0.070456 seconds
[ INFO] [1470606502.824677454]: SimpleSetup: Path simplification took 0.000493 seconds and changed from 3 to 2 states
[ INFO] [1470606502.829340760]: Received new trajectory execution service request...
[ INFO] [1470606504.651201818]: Execution completed: SUCCEEDED
[ INFO] [1470606505.912313522]: Received request to compute Cartesian path
[ INFO] [1470606505.912874758]: Attempting to follow 2 waypoints for link 'ur5_arm_marker_link' using a step of 0.010000 m and jump threshold 0.000000 (in global reference frame)
[ INFO] [1470606508.899455833]: Computed Cartesian path with 58 points (followed 100.000000% of requested trajectory)
[ INFO] [1470606508.906403401]: Received new trajectory execution service request...
[ INFO] [1470606511.885918977]: Execution completed: SUCCEEDED
**[ INFO] [1470606511.890627476]: Received request to compute Cartesian path
[ INFO] [1470606511.890953046]: Attempting to follow 2 waypoints for link 'ur5_arm_marker_link' using a step of 0.010000 m and jump threshold 0.000000 (in global reference frame)
[ INFO] [1470606513.256998251]: Computed Cartesian path with 27 points (followed 100.000000% of requested trajectory)
[ INFO] [1470606513.262543511]: Received new trajectory execution service request...
[ WARN] [1470606513.263840859]: Controller arm_controller failed with error code INVALID_GOAL
[ WARN] [1470606513.263936079]: Controller handle arm_controller reports status FAILED
[ INFO] [1470606513.264018256]: Execution completed: FAILED**
[ INFO] [1470606513.265924877]: Received request to compute Cartesian path
[ INFO] [1470606513.266154401]: Attempting to follow 2 waypoints for link 'ur5_arm_marker_link' using a step of 0.010000 m and jump threshold 0.000000 (in global reference frame)
[ INFO] [1470606516.585900623]: Computed Cartesian path with 64 points (followed 100.000000% of requested trajectory)
[ INFO] [1470606516.591274222]: Received new trajectory execution service request...
[ INFO] [1470606520.105039153]: Execution completed: SUCCEEDED
**[ INFO] [1470606520.107687355]: Received request to compute Cartesian path
[ INFO] [1470606520.107977450]: Attempting to follow 2 waypoints for link 'ur5_arm_marker_link' using a step of 0.010000 m and jump threshold 0.000000 (in global reference frame)
[ INFO] [1470606521.445493228]: Computed Cartesian path with 27 points (followed 100.000000% of requested trajectory)
[ INFO] [1470606521.453115526]: Received new trajectory execution service request...
[ WARN] [1470606521.454731340]: Controller arm_controller failed with error code INVALID_GOAL
[ WARN] [1470606521.454904598]: Controller handle arm_controller reports status FAILED
[ INFO] [1470606521.455072531]: Execution completed: FAILED**
[ INFO] [1470606521.457603549]: Combined planning and execution request received for MoveGroup action. Forwarding to planning and execution pipeline.
[ INFO] [1470606521.457719245]: Planning attempt 1 of at most 5
[ INFO] [1470606521.459060714]: RRTConnect: Starting planning with 1 states already in datastructure
[ INFO] [1470606521.472863524]: RRTConnect: Created 4 states (2 start + 2 goal)
[ INFO] [1470606521.480973790]: Solution found in 0.022110 seconds
[ INFO] [1470606521.483070776]: SimpleSetup: Path simplification took 0.001920 seconds and changed from 3 to 2 states
[ INFO] [1470606527.690005836]: Received event 'stop'
[ INFO] [1470606527.690275769]: Combined planning and execution request received for MoveGroup action. Forwarding to planning and execution pipeline.
[ INFO] [1470606527.690327849]: Planning attempt 1 of at most 5
[ INFO] [1470606527.690454600]: Starting state is just outside bounds (joint 'ur5_arm_wrist_1_joint'). Assuming within bounds.
[ INFO] [1470606527.691189388]: RRTConnect: Starting planning with 1 states already in datastructure
[ INFO] [1470606527.715571919]: RRTConnect: Created 4 states (2 start + 2 goal)
[ INFO] [1470606527.716842772]: Solution found in 0.025781 seconds
[ INFO] [1470606527.716900227]: SimpleSetup: Path simplification took 0.000013 seconds and changed from 3 to 2 states
[ INFO] [1470606527.717317337]: Planning adapters have added states at index positions: [ 0 ]

While the Fetch executes every trajectory, at the end of some of the trajectories (sometimes all of them, except the last), the arm will move back to a position along the Cartesian path

and repeat much of the last trajectory before beginning the next. The Moveit! terminal output is included below. In addition, I have linked to a video due to GitHub not letting me add it as a .zip. (https://drive.google.com/file/d/0B8QbGCFcn-dwYU55cXQ0SU5oamM/view?usp=sharing)

[ INFO] [1470607840.318662060]: Combined planning and execution request received for MoveGroup action. Forwarding to planning and execution pipeline.
[ INFO] [1470607840.318808855]: Planning attempt 1 of at most 5
[ INFO] [1470607840.325326234]: No planner specified. Using default.
[ INFO] [1470607840.325449348]: LBKPIECE1: Attempting to use default projection.
[ INFO] [1470607840.326953858]: LBKPIECE1: Starting planning with 1 states already in datastructure
[ INFO] [1470607840.478435172]: LBKPIECE1: Created 57 (8 start + 49 goal) states in 42 cells (7 start (7 on boundary) + 35 goal (35 on boundary))
[ INFO] [1470607840.478483011]: Solution found in 0.152855 seconds
[ INFO] [1470607840.479726155]: SimpleSetup: Path simplification took 0.001129 seconds and changed from 24 to 2 states
[ INFO] [1470607845.159145777]: Planning request received for MoveGroup action. Forwarding to planning pipeline.
[ INFO] [1470607845.162410200]: No planner specified. Using default.
[ INFO] [1470607845.162452518]: LBKPIECE1: Attempting to use default projection.
[ INFO] [1470607845.163552137]: LBKPIECE1: Starting planning with 1 states already in datastructure
[ INFO] [1470607845.343225032]: LBKPIECE1: Created 27 (12 start + 15 goal) states in 24 cells (11 start (11 on boundary) + 13 goal (13 on boundary))
[ INFO] [1470607845.343365727]: Solution found in 0.180874 seconds
[ INFO] [1470607845.386835195]: SimpleSetup: Path simplification took 0.004402 seconds and changed from 14 to 2 states
[ INFO] [1470607845.405667133]: Received new trajectory execution service request...
[ INFO] [1470607849.518333136]: Execution completed: SUCCEEDED
[ INFO] [1470607850.774847453]: Received request to compute Cartesian path
[ INFO] [1470607850.775077716]: Attempting to follow 2 waypoints for link 'wrist_roll_link' using a step of 0.010000 m and jump threshold 0.000000 (in global reference frame)
[ INFO] [1470607853.644398866]: Computed Cartesian path with 58 points (followed 100.000000% of requested trajectory)
[ INFO] [1470607853.646321709]: Received new trajectory execution service request...
[ INFO] [1470607865.433584192]: Execution completed: SUCCEEDED
[ INFO] [1470607865.435228287]: Received request to compute Cartesian path
[ INFO] [1470607865.435497986]: Attempting to follow 2 waypoints for link 'wrist_roll_link' using a step of 0.010000 m and jump threshold 0.000000 (in global reference frame)
[ INFO] [1470607869.526370248]: Computed Cartesian path with 82 points (followed 100.000000% of requested trajectory)
[ INFO] [1470607869.528837090]: Received new trajectory execution service request...
[ INFO] [1470607886.033478353]: Execution completed: SUCCEEDED
[ INFO] [1470607886.034956138]: Received request to compute Cartesian path
[ INFO] [1470607886.035082853]: Attempting to follow 2 waypoints for link 'wrist_roll_link' using a step of 0.010000 m and jump threshold 0.000000 (in global reference frame)
[ INFO] [1470607890.075843317]: Computed Cartesian path with 81 points (followed 100.000000% of requested trajectory)
[ INFO] [1470607890.077995486]: Received new trajectory execution service request...
[ INFO] [1470607906.283832539]: Execution completed: SUCCEEDED
[ INFO] [1470607906.285818011]: Received request to compute Cartesian path
[ INFO] [1470607906.285920761]: Attempting to follow 2 waypoints for link 'wrist_roll_link' using a step of 0.010000 m and jump threshold 0.000000 (in global reference frame)
[ INFO] [1470607910.364466796]: Computed Cartesian path with 82 points (followed 100.000000% of requested trajectory)
[ INFO] [1470607910.366617598]: Received new trajectory execution service request...
[ INFO] [1470607926.878415544]: Execution completed: SUCCEEDED
[ INFO] [1470607926.879282723]: Combined planning and execution request received for MoveGroup action. Forwarding to planning and execution pipeline.
[ INFO] [1470607926.879340369]: Planning attempt 1 of at most 5
[ INFO] [1470607926.882826435]: LBKPIECE1: Starting planning with 1 states already in datastructure
[ INFO] [1470607926.983473584]: LBKPIECE1: Created 30 (19 start + 11 goal) states in 23 cells (18 start (18 on boundary) + 5 goal (5 on boundary))
[ INFO] [1470607926.983519283]: Solution found in 0.101442 seconds
[ INFO] [1470607927.067627948]: SimpleSetup: Path simplification took 0.084048 seconds and changed from 16 to 17 states
[ INFO] [1470607935.318948160]: Received event 'stop'
[ INFO] [1470607935.319185843]: Combined planning and execution request received for MoveGroup action. Forwarding to planning and execution pipeline.
[ INFO] [1470607935.319235286]: Planning attempt 1 of at most 5
[ INFO] [1470607935.326490876]: LBKPIECE1: Starting planning with 1 states already in datastructure
[ INFO] [1470607935.427244565]: LBKPIECE1: Created 38 (27 start + 11 goal) states in 31 cells (26 start (26 on boundary) + 5 goal (5 on boundary))
[ INFO] [1470607935.427405089]: Solution found in 0.102788 seconds
[ INFO] [1470607935.427739310]: SimpleSetup: Path simplification took 0.000018 seconds and changed from 18 to 2 states
#!/usr/bin/env python

"""
    corner_prediction.py - Version 0.1 2016-08-07

    Use Moveit to seal a window frame

    This program is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation; either version 2 of the License, or
    (at your option) any later version.5

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details at:

    http://www.gnu.org/licenses/gpl.html
"""

import rospy
import sys
import moveit_commander
from geometry_msgs.msg import PoseArray, PoseStamped, Pose
from copy import deepcopy

class CornerPrediction:
    def __init__(self):
        #Give the node a name
        rospy.init_node("corner_prediction", anonymous=False)

        rospy.loginfo("Starting node seal_prediction")

        rospy.on_shutdown(self.cleanup)

        # Initialize the move_group API
        moveit_commander.roscpp_initialize(sys.argv)

        # Initialize the move group for the ur5_arm
    self.robot= moveit_commander.RobotCommander()
        #Uncomment for Husky
        #self.arm = self.robot.ur5_arm
        self.arm = self.robot.arm_with_torso

        # Get the name of the end-effector link
        end_effector_link = self.arm.get_end_effector_link()

        # Set the reference frame for pose targets
        reference_frame = "/base_link"

        # Set the ur5_arm reference frame accordingly
        self.arm.set_pose_reference_frame(reference_frame)

        # Allow replanning to increase the odds of a solution
        self.arm.allow_replanning(True)

        # Allow some leeway in position (meters) and orientation (radians)
        self.arm.set_goal_position_tolerance(0.001)
        self.arm.set_goal_orientation_tolerance(0.001)

        # Start the arm in the work pose stored in the SRDF file
        self.arm.set_named_target("work")
        self.arm.go()
        rospy.sleep(2)

        corner_locations = rospy.wait_for_message("/initial_locations_seal", PoseArray)

        # Initialize needed variables
        traj = None    
        location = 1
        corner_pose = corner_locations.poses[0]

        #Move the end effecor to the x - .45, y, z positon
        #Set the target pose to the hole location in the base_link frame
        target_pose = PoseStamped()
        target_pose.header.frame_id = reference_frame
        target_pose.header.stamp = rospy.Time.now()
        target_pose.pose.position.x = corner_pose.position.x - 0.1
        target_pose.pose.position.y = corner_pose.position.y
        target_pose.pose.position.z = corner_pose.position.z
        target_pose.pose.orientation.x = corner_pose.orientation.x
        target_pose.pose.orientation.y = corner_pose.orientation.y
        target_pose.pose.orientation.z = corner_pose.orientation.z
        target_pose.pose.orientation.w = corner_pose.orientation.w

        # Set the start state to the current state
        self.arm.set_start_state_to_current_state()

        # Set the goal pose of the end effector to the stored pose
        self.arm.set_pose_target(target_pose, end_effector_link)

        # Plan the trajectory to the goal
        traj = self.arm.plan()

        if traj is not None:
            # Execute the planned trajectory
            self.arm.execute(traj)

            # Pause for a second
            rospy.sleep(1)

            rospy.loginfo("Successfully moved to corner " + str(location))

        else:
            rospy.loginfo("Unable to reach corner " + str(location))

    seal_locations = deepcopy(corner_locations)
    seal_locations.poses.append(corner_locations.poses[0])

        # Set the target pose
        for corner_pose in seal_locations.poses[1:]:

            #Move the end effecor to the x - 0.1, y, z positon
            #Set the target pose to the hole location in the base_link frame
            target_pose = Pose()
            target_pose.position.x = corner_pose.position.x - 0.1
            target_pose.position.y = corner_pose.position.y
            target_pose.position.z = corner_pose.position.z
            target_pose.orientation.x = corner_pose.orientation.x
            target_pose.orientation.y = corner_pose.orientation.y
            target_pose.orientation.z = corner_pose.orientation.z
            target_pose.orientation.w = corner_pose.orientation.w


            fraction = 0.0
            attempts = 0
            plan = None

            **start_pose = self.arm.get_current_pose(end_effector_link).pose

            # Set the start state to the current state
            self.arm.set_start_state_to_current_state()**

            # Plan the Cartesian path connecting the start point and goal
            while fraction < 1.0 and attempts < 100:
                (plan, fraction) = self.arm.compute_cartesian_path


([start_pose, target_pose],   # waypoint poses
                                                                    0.01,        # eef_step
                                                                    0.0,         # jump_threshold
                                                                    False)        # avoid_collisions

                # Increment the number of attempts
                attempts += 1

            # If we have a complete plan, return that plan
            if fraction == 1.0:
                #Uncomment for Husky
                #plan = self.arm.retime_trajectory(self.robot.get_current_state(), plan, 1.0)
                self.arm.execute(plan)
                rospy.loginfo("Successfully sealed section " + str(location))
                location += 1

            else:
                rospy.loginfo("Unable to seal section " + str(location))
                location += 1
                continue

        # Finish the ur5_arm in the stow pose stored in the SRDF file
        self.arm.set_named_target("stow")
        self.arm.go()
        rospy.sleep(2)

    def cleanup(self):
        rospy.loginfo("Stopping the robot")

        # Stop any current arm movement
        self.arm.stop()

        # Move the arm to the stow position
        self.arm.set_named_target("stow")
        self.arm.go()

        #Shut down MoveIt! cleanly
        rospy.loginfo("Shutting down Moveit!")
        moveit_commander.roscpp_shutdown()
        moveit_commander.os._exit(0)


if __name__ == "__main__":
  try:
    CornerPrediction()
  except KeyboardInterrupt:
      print "Shutting down CornerPrediction node."

Thank you for any help you are able to provide, as well as your time and attention to this matter. Have a great week. God bless.

Very Respectfully,
CMobley7

[kinetic] Undefined reference to setCollisionObjectUpdateCallback

I'm getting another nasty undefined reference error in moveit kinetic while trying to compile something that used to work in indigo using moveit.

/home/jettan/workspace/ros/devel/lib/libmoveit_planning_scene_monitor.so: undefined reference to `planning_scene::PlanningScene::setCollisionObjectUpdateCallback(boost::function<void (boost::shared_ptr<collision_detection::World::Object const> const&, collision_detection::World::Action)> const&)'

I already tried to rebuild moveit_ros_planning and planning_scene_monitor over and over again.
Any idea if anything changed that might have caused this issue?

I know the function exist as a grep command outputs the following:

$ grep -r "setCollisionObjectUpdateCallback"
moveit_core/planning_scene/include/moveit/planning_scene/planning_scene.h:  void setCollisionObjectUpdateCallback(const collision_detection::World::ObserverCallbackFn &callback);
moveit_core/planning_scene/src/planning_scene.cpp:void planning_scene::PlanningScene::setCollisionObjectUpdateCallback(const collision_detection::World::ObserverCallbackFn &callback)
moveit_ros/planning/planning_scene_monitor/src/planning_scene_monitor.cpp:    scene_->setCollisionObjectUpdateCallback(collision_detection::World::ObserverCallbackFn());
moveit_ros/planning/planning_scene_monitor/src/planning_scene_monitor.cpp:      scene_->setCollisionObjectUpdateCallback(boost::bind(&PlanningSceneMonitor::currentWorldObjectUpdateCallback, this, _1, _2));
moveit_ros/planning/planning_scene_monitor/src/planning_scene_monitor.cpp:        scene_->setCollisionObjectUpdateCallback(collision_detection::World::ObserverCallbackFn());
moveit_ros/planning/planning_scene_monitor/src/planning_scene_monitor.cpp:        scene_->setCollisionObjectUpdateCallback(boost::bind(&PlanningSceneMonitor::currentWorldObjectUpdateCallback, this, _1, _2));
moveit_ros/planning/planning_scene_monitor/src/planning_scene_monitor.cpp:          scene_->setCollisionObjectUpdateCallback(collision_detection::World::ObserverCallbackFn());
moveit_ros/planning/planning_scene_monitor/src/planning_scene_monitor.cpp:          scene_->setCollisionObjectUpdateCallback(boost::bind(&PlanningSceneMonitor::currentWorldObjectUpdateCallback, this, _1, _2));
moveit_ros/planning/planning_scene_monitor/src/planning_scene_monitor.cpp:      scene_->setCollisionObjectUpdateCallback(collision_detection::World::ObserverCallbackFn());
moveit_ros/planning/planning_scene_monitor/src/planning_scene_monitor.cpp:      scene_->setCollisionObjectUpdateCallback(boost::bind(&PlanningSceneMonitor::currentWorldObjectUpdateCallback, this, _1, _2));

Apply clang-tidy code linter

OMPL has been upgrading its code to be faster, follow best practices, and use C++11 by using the automated tool clang-tidy. Would be great to use this linter tool here too.

It consists of lots of individual checks that will propose or even alter the code. I think each check should be run separate with individual pull requests to the codebase.

Migrate remaining Pull Requests from old repos

There are still a lot of pull requests in various old MoveIt repos, especially moveit_ros:

If you are up to it - rebase, cleanup, and reopen those pull requests to the new repo.

Note: do not claim this issue - it is a meta-issue containing a lot of work. Instead claim the particular pull request you want to work on on the corresponding old PR.

[kinetic] Missing dependency to moveit_msgs from move_group

I'm getting errors trying to compile move_group in the kinetic branch because of some missing dependencies to moveit_msgs in the CMakeLists.txt.

Error:

In file included from /home/jettan/workspace/ros/src/overlay/moveit/moveit_ros/move_group/src/default_capabilities/apply_planning_scene_service_capability.cpp:37:0:
/home/jettan/workspace/ros/src/overlay/moveit/moveit_ros/move_group/src/default_capabilities/apply_planning_scene_service_capability.h:41:44: fatal error: moveit_msgs/ApplyPlanningScene.h: No such file or directory
 #include <moveit_msgs/ApplyPlanningScene.h>
                                            ^
compilation terminated.
In file included from /home/jettan/workspace/ros/src/overlay/moveit/moveit_ros/move_group/src/default_capabilities/query_planners_service_capability.cpp:37:0:
/home/jettan/workspace/ros/src/overlay/moveit/moveit_ros/move_group/src/default_capabilities/query_planners_service_capability.h:42:42: fatal error: moveit_msgs/GetPlannerParams.h: No such file or directory
 #include <moveit_msgs/GetPlannerParams.h>

`catkin_lint` packages

In an initial attempt (e.g. moveit/moveit_core#305) I ran catkin_lint on moveit_core, geometric_shapes and some other repos and cleaned up many issues spotted by the linter.

Many of MoveIt's ROS-packages still produce a number of errors.
This is your chance to change that and prevent future problems with broken dependencies, broken CMakeLists constructs, issues to port packages from OSRF's /opt/ folder to /usr, etc. :-)

A few issues reported by catkin_lint are false-positives or explicit decisions by the maintainers.

The most famous one is:

moveit_core: CMakeLists.txt(6): error: variable CMAKE_BUILD_TYPE is modified

It was decided that MoveIt should default to "Release" build type for maximum performance, so this is no error.


As this touches a number of different packages, please do not assign to this ticket.
Instead, find yourself a moveit package `catkin_lint` complains about, add a note saying you are looking into this package and submit one pull-request for each package you clean.

commander: Segmentation fault on wrong or no robot model

As we had to merge this revert to fix PlanningSceneMonitor & RViz segfaults, this issue exists again.

#46 should fix it again, but it depends on an RViz bug fix (see the description there).

Quote of the original issue:

I am trying to follow the python tutorial, but this simple file already crashes:

!/usr/bin/python

import sys
import copy
import rospy
import moveit_commander
import moveit_msgs.msg
import geometry_msgs.msg

print "============ Starting tutorial setup"
moveit_commander.roscpp_initialize(sys.argv)
rospy.init_node('move_group_python_interface_tutorial',
anonymous=True)

robot = moveit_commander.RobotCommander()

And the result in a segmentation fault.

Here is a backtrace: http://pastebin.com/3bftAaaj

I am trying to get MoveIt to work with Amigo (https://github.com/tue-robotics/amigo_moveit_config). But I get the same error if I only have a roscore running. (No parameters loaded).

moveit_commander fails in Kinetic due to pyassimp regression

In Xenial with pyassimp 3.2, importing moveit_commander fails with:

>>> import moveit_commander
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/vol/sandbox/ros/install/lib/python2.7/dist-packages/moveit_commander/__init__.py", line 3, in <module>
    from planning_scene_interface import *
  File "/vol/sandbox/ros/install/lib/python2.7/dist-packages/moveit_commander/planning_scene_interface.py", line 48, in <module>
    import pyassimp
  File "/usr/lib/python2.7/dist-packages/pyassimp/__init__.py", line 1, in <module>
    from .core import *
  File "/usr/lib/python2.7/dist-packages/pyassimp/core.py", line 23, in <module>
    from . import structs
ImportError: cannot import name structs

@davetcoleman Did you ever tried to run moveit from python in kinect?

Proposal: Adding a CMakeModules directory

There doesn't seem to be a common CMakeModules directory for this repo. This would be useful for storing CMake files that are required for multiple packages e.g. the Coveralls cmake modules that will be required for issue #1. One place to put this would be moveit/CMakeModules, that is at a higher level than all of the packages in this repo.

Having a common CMakeModules could also be useful for reducing code repetition across packages. For example, packages in this repo generally have some code in their CMakeLists.txt that sets the default build type to release. It typically looks like this (taken from moveit_core):


if(NOT CMAKE_CONFIGURATION_TYPES AND NOT CMAKE_BUILD_TYPE)
  message("${PROJECT_NAME}: You did not request a specific build type: Choosing 'Release' for maximum performance")
  set(CMAKE_BUILD_TYPE Release)
endif()

Porting CHOMP to latest MoveIt

I recently started trying to port the CHOMP planner to the latest moveit API.
I have worked a bit on (https://github.com/jhu-lcsr-forks/moveit_planners). For now, the moveit plugin for planning compiles and runs with moveit. Please find my fork here: https://github.com/ksatyaki/moveit_planners

However, I need some insight to figure out why I get this error.

Could not initialize hybrid collision world from planning scene
Could not initialize optimizer

These are errors generated when creating an optimizer instance.

I tried running it on a jaco2 arm.I didn't configure a kinect / 3d sensor. I first wanted to try it without any obstacles. Am I missing something?

Please let me know if you need more information. Any help is highly appreciated.

My launch files are at:
https://github.com/ksatyaki/jaco_chomp_launch
https://github.com/ksatyaki/manipulation_launch

I run the manipulation.launch from jaco_chomp_launch which basically loads move_group with a different planning pipeline.

add "<previous>" robot state to RViz motion display

In some situations it would be nice to have a "" entry in the Update Start/Goal State drop-down list, to set the start/goal state of the display to the previous pose the robot was in (before the latest motion). This can be used e.g. to look for alternative paths for the latest robot motion.

This could be implemented by adding a new robot_state::RobotState previous_state_ member to the MotionPlanningDisplay that is updated after each successful execution (as well as plan&execute) and might be used by MotionPlanningFrame::updateQueryStateHelper to set a query state.

get rid of "catkin_package() exports non-package include path"

moveit_core currently exports the header file "devel/include/moveit/version.h".
Because this is not a path specifically for moveit_core, catkin_lint . in the moveit_core source folder (rightfully) complains:

moveit_core: CMakeLists.txt(77): error: catkin_package() exports non-package include path

The file should probably be generated in "devel/include/moveit_core/moveit/version.h" (using appropriate catkin-variables for the prefix).

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.