There are several failed ROS tests commented out because they would cause CI to fail as well. All of these should be fixed and run under ROS2.

Description

Overview of your issue here.
While building moveit2 following the instructions given in the main README.md I get the following build error

Failed   <<< moveit_simple_controller_manager	[ Exited with code 1 ]
--- stderr: moveit_ros_occupancy_map_monitor
CMake Error at .../moveit2_ws/install/moveit_core/share/moveit_core/cmake/ament_cmake_export_libraries-extras.cmake:48 (message):
  Package 'moveit_core' exports the library 'moveit_exceptions' which
  couldn't be found
Call Stack (most recent call first):
  ...t/moveit2_ws/install/moveit_core/share/moveit_core/cmake/moveit_coreConfig.cmake:38 (include)
  CMakeLists.txt:25 (find_package)

Your environment

• ROS Distro: [eloquent]
• OS Version: Ubuntu 18.04
• Source build
• master branch

Steps to reproduce

Follow build instructions in README.md

 git clone https://github.com/ros-planning/moveit2.git -b master
 vcs import < moveit2/moveit2.repos
 rosdep install -r --from-paths . --ignore-src --rosdistro eloquent -y

 cd $COLCON_WS
 colcon build --event-handlers desktop_notification- status- --cmake-args -DCMAKE_BUILD_TYPE=Release

Expected behaviour

Build should finish without errors

Actual behaviour

Build errors out with the error message shown above

I am building the moveit2 on windows 10.
When I build the moveit2,moveit_core not find pkg_config,so I pip install pkg_config.
but when I colcon build --merge-install ,it happend the Error:

CMake Error at CMakeLists.txt:32 (pkg_check_modules):
Unknown CMake command "pkg_check_modules".

What should I do?Thanks for your reply

In ROS 2 we have two ways to write launch files

• Python API
• XML based (It's not supported in dashing, but it does in eloquent)

Even if we decided to move on with XML based one we have to do some migration steps see

Reference

/usr/bin/ld: cannot find -lEigen3::Eigen
collect2: error: ld returned 1 exit status
make[2]: *** [robot_model/libmoveit_robot_model.so.2.0.0] Error 1
make[1]: *** [robot_model/CMakeFiles/moveit_robot_model.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

Description

The image that is using for the CI is outdated and is failing because of changes in the key.

Error:

• https://travis-ci.org/ros-planning/moveit2/builds/539939904#L236-L237

I you rebuild the image solves the issue: https://discourse.ros.org/t/key-rotation-for-ros-2-apt-repositories/9363

MoveIt 1 uses rostest a fair amount. In ROS 2 the exact replacement is still under development according to @wjwwood so there is not great documentation yet.

This issue will track the progress of us understanding how to do the conversion.

We need to re-implement runtime updates of node parameters using dynamic_reconfigure.
A rather straight-forward approach would use parameter event callbacks as shown in this example:
https://github.com/ros2/tutorials/blob/master/rclcpp_tutorials/src/parameters/parameter_events.cpp

The only downside I see is that we don't automatically register "configurable nodes" and there is no reconfigure_gui anymore. Also, we will need to update the client sides or at least provide migration steps.

One example where dynamic_reconfigure is used in the ompl planner interface: https://github.com/ros-planning/moveit2/blob/cd27142259e13d4b34072bdc6e823288cc234d99/moveit_planners/ompl/ompl_interface/src/ompl_planner_manager.cpp#L262

@mkhansen-intel how did you handle this with navigation2?

Description

We followed moveit-2-journey-first-demonstrator/ to reproduce the first demonstrator of MoveIt2 with MARA robot. However, either the effort with the pre-built docker container or with the source build failed.

Your environment

• ROS Distro: dashing
• OS Version: Ubuntu 18.04
• RMW: FastRTPS

Problems

1. Failure with the docker container

• Using https://github.com/AcutronicRobotics/MARA dashing branch

At first, we tried the instructions using docker container acutronicrobotics/moveit2:dashing-alpha.

At the first terminal:

ros2 launch mara_gazebo mara.launch.py

At the second terminal:

docker run --rm -it --net=host --name moveit2 acutronicrobotics/moveit2:dashing-alpha

At the third terminal:

docker exec -it moveit2 bash /root/run_execute.bash

We have paid attention to source the ROS2 environment, and changed the script in the docker so that both the gazebo mara and the docker container use the same RMW.

It seemed that the path planning managed to succeed, which printed:

[INFO] [moveit_ros_planning.move_group_interface]: Ready to take commands for planning group manipulator .
[INFO] [move_group_interface_demo]: Listening to joint states on topic 'joint_states'
current state! ok!
[INFO] [move_group_interface_demo]: Reference frame: world
[INFO] [move_group_interface_demo]: End effector link: ee_link
current state! ok!
[INFO] [move_group_interface_demo]: Visualizing plan 2 (joint space goal) 
6 6 6
motor1 0.00000
motor2 0.00000
motor3 0.00001
motor4 0.00000
motor5 0.00000
motor6 -0.00000
0.00000	0.00000	0.00001	0.00000	0.00000	-0.00000	
time_from_start 0 0
-0.04774	0.00000	0.07495	-0.00000	0.00001	-0.00000	
time_from_start 0 387732368
-0.09547	0.00001	0.14989	-0.00000	0.00001	-0.00000	
time_from_start 0 549350976
-0.14321	0.00001	0.22483	-0.00001	0.00002	-0.00000	
time_from_start 0 673603846
-0.19094	0.00001	0.29977	-0.00001	0.00002	-0.00000	
time_from_start 0 779779955
-0.23584	0.00001	0.37025	-0.00001	0.00002	-0.00000	
time_from_start 0 868979284
-0.28074	0.00001	0.44074	-0.00001	0.00003	-0.00000	
time_from_start 0 949730274
-0.31535	0.00001	0.49507	-0.00001	0.00003	-0.00000	
time_from_start 1 8374859
-0.34996	0.00002	0.54941	-0.00002	0.00003	-0.00000	
time_from_start 1 68796433
-0.36400	0.00002	0.57145	-0.00002	0.00003	-0.00000	
time_from_start 1 94051680
-0.37804	0.00002	0.59350	-0.00002	0.00003	-0.00000	
time_from_start 1 119559479
-0.39386	0.00002	0.61833	-0.00002	0.00003	-0.00000	
time_from_start 1 148869276
-0.40967	0.00002	0.64316	-0.00002	0.00003	-0.00000	
time_from_start 1 178768200
-0.44961	0.00002	0.70586	-0.00002	0.00003	-0.00000	
time_from_start 1 258113284
-0.48954	0.00002	0.76855	-0.00002	0.00003	-0.00000	
time_from_start 1 344891834
-0.53395	0.00002	0.83828	-0.00002	0.00003	-0.00000	
time_from_start 1 453881888
-0.57836	0.00002	0.90801	-0.00003	0.00003	-0.00001	
time_from_start 1 585777697
-0.60762	0.00002	0.95395	-0.00003	0.00003	-0.00001	
time_from_start 1 698602412
-0.63687	0.00002	0.99988	-0.00003	0.00003	-0.00001	
time_from_start 1 790660446
-0.65855	0.00002	1.03391	-0.00003	0.00003	-0.00001	
time_from_start 1 851070226
-0.68022	0.00002	1.06795	-0.00003	0.00003	-0.00001	
time_from_start 1 910287989
-0.69732	0.00002	1.09478	-0.00003	0.00003	-0.00001	
time_from_start 1 954027427
-0.71441	0.00002	1.12162	-0.00003	0.00002	-0.00001	
time_from_start 1 995471971
-0.73786	0.00002	1.15845	-0.00003	0.00002	-0.00001	
time_from_start 2 49036601
-0.76131	0.00002	1.19527	-0.00003	0.00001	-0.00001	
time_from_start 2 99496906
-0.79747	0.00002	1.25205	-0.00003	0.00001	-0.00001	
time_from_start 2 183765961
-0.83363	0.00002	1.30884	-0.00003	-0.00000	-0.00002	
time_from_start 2 279611802
-0.86794	0.00002	1.36273	-0.00003	-0.00001	-0.00002	
time_from_start 2 387853104
-0.90226	0.00002	1.41662	-0.00003	-0.00002	-0.00002	
time_from_start 2 528803751
-0.92017	0.00002	1.44475	-0.00003	-0.00002	-0.00002	
time_from_start 2 625483932
-0.93809	0.00002	1.47289	-0.00003	-0.00003	-0.00002	
time_from_start 2 735167723
-0.94780	0.00002	1.48814	-0.00003	-0.00003	-0.00002	
time_from_start 2 832127566
-0.95751	0.00002	1.50339	-0.00003	-0.00003	-0.00002	
time_from_start 2 897111693
-0.96811	0.00002	1.52004	-0.00003	-0.00004	-0.00002	
time_from_start 2 954108144
-0.97871	0.00002	1.53669	-0.00003	-0.00004	-0.00003	
time_from_start 3 12831644
-0.98932	0.00002	1.55334	-0.00003	-0.00005	-0.00003	
time_from_start 3 88446753
-0.99992	0.00002	1.56999	-0.00003	-0.00005	-0.00003	
time_from_start 3 274094882

However, the follow_joint_trajectoryaction_server failed to execute the trajectory, and the MARA robot in gazebo didn't move, which prints:

[INFO] [move_group]: Starting trajectory execution ...
[INFO] [follow_joint_trajectoryaction_server]: Received goal request with order
[INFO] [follow_joint_trajectoryaction_server]: handle_accepted and executing
  moveit_controller_manager::MoveItControllerHandlePtr getControllerHandle follow_joint_trajectory[INFO] [moveit.SimpleControllerManager]: Goal accepted by server, waiting for result
handles[i]->waitForExecution(expected_trajectory_duration);
ActionBasedControllerHandleBase waitForExecution
done_ 0 timeout 0.00000
[WARN] [move_group]: Controller handle follow_joint_trajectory reports status 1
epart 0
execution_complete_ 0
ALEX waitForRobotToStop ?? 1
[INFO] [move_group]: Completed trajectory execution with status RUNNING ...
2 execution_complete_ 1
1 continuous_execution_queue_ 1
2 continuous_execution_queue_ 1
waitForExecution end 
[INFO] [move_group]: Execution completed: RUNNING
[INFO] [follow_joint_trajectoryaction_server]: /hrim_actuation_servomotor_000000000001/trajectory_axis2: failed
[INFO] [follow_joint_trajectoryaction_server]: /hrim_actuation_servomotor_000000000001/trajectory_axis1: failed
[INFO] [follow_joint_trajectoryaction_server]: /hrim_actuation_servomotor_000000000002/trajectory_axis1: failed
[INFO] [follow_joint_trajectoryaction_server]: /hrim_actuation_servomotor_000000000002/trajectory_axis2: failed
[INFO] [follow_joint_trajectoryaction_server]: /hrim_actuation_servomotor_000000000003/trajectory_axis1: failed
[INFO] [follow_joint_trajectoryaction_server]: /hrim_actuation_servomotor_000000000003/trajectory_axis2: failed
[ERROR] [follow_joint_trajectoryaction_server]: Not all action server ready. Exit.
[INFO] [moveit.SimpleControllerManager]: Controller follow_joint_trajectory successfully finished

2. Failure with the source build

• https://github.com/AcutronicRobotics/MARA dashing
• https://github.com/AcutronicRobotics/moveit2 master

At the first terminal, run:

ros2 launch mara_gazebo mara.launch.py

At the second terminal, run:

gdb -ex run --args build/moveit_ros_move_group/move_group

At the third terminal, run:

ros2 launch <path_to_ros2_workspace_src>/moveit2/moveit_ros/planning/trajectory_execution_manager/test/test_app.launch.py

The URDF and SRDF in test_app.launch.py was edited to:

urdf = os.path.join(get_package_share_directory('mara_description'), 'urdf', 'mara_robot.urdf')
srdf = "<path_to_ros2_workspace_src>/moveit_resources/mara_moveit_config/config/mara.srdf"

After this step, the move_group supposed to be initialized, but it finished with a segmentation fault rclcpp::Node::get_node_services_interface() () from /opt/ros/dashing/lib/librclcpp.so in the second terminal, and printed:

[INFO] [moveit.rdf_loader]: Loaded robot model in 0.4196 seconds
[INFO] [robot_model]: Loading robot model 'mara'...
[WARN] [robot_model]: Skipping virtual joint 'fixed_base' because its child frame 'base_link' does not match the URDF frame 'world'
[INFO] [robot_model]: No root/virtual joint specified in SRDF. Assuming fixed joint
[INFO] [kinematics_plugin_loader]: Configuring kinematics solvers
[INFO] [kinematics_plugin_loader]: Loading settings for kinematics solvers from the ROS param server ...
[INFO] [kinematics_plugin_loader]: Looking for param manipulator.kinematics_solver 
[INFO] [kinematics_plugin_loader]: Looking for param robot_description_kinematics.manipulator.kinematics_solver 
[INFO] [kinematics_plugin_loader]: Using kinematics solver 'kdl_kinematics_plugin/KDLKinematicsPlugin' for group 'manipulator'.
[INFO] [kinematics_plugin_loader]: 1 param is kdl_kinematics_plugin/KDLKinematicsPlugin 
[INFO] [kinematics_plugin_loader]: Looking for param endeffector.kinematics_solver 
[INFO] [kinematics_plugin_loader]: Looking for param robot_description_kinematics.endeffector.kinematics_solver 
[INFO] [kinematics_plugin_loader]: Using kinematics solver 'not' for group 'endeffector'.
[INFO] [kinematics_plugin_loader]: Using kinematics solver 'set' for group 'endeffector'.
[INFO] [kinematics_plugin_loader]: 1 param is not set 
[INFO] [kinematics_plugin_loader]: Trying to allocate kinematics solver for group 'manipulator'
[INFO] [kinematics_plugin_loader]: Choosing tip frame of kinematic solver for groupbased on last link in chain
[INFO] [kinematics_plugin_loader]: Planning group 'manipulator' has tip(s): ee_link, 
Link base_link had 1 children
Link base_robot had 1 children
Link motor1_link had 2 children
Link motor1_cover had 0 children
Link motor2_link had 1 children
Link motor3_link had 2 children
Link motor3_cover had 0 children
Link motor4_link had 1 children
Link motor5_link had 2 children
Link motor5_cover had 0 children
Link motor6_link had 2 children
Link ee_link had 0 children
Link tool0 had 0 children

Did anyone succeed to reproduce the first demonstrator of MoveIt2? Did I miss something?

Description

Some commits are applied for multiple packages at once, I would recommend porting these commits as they are rather than applying the change to each package and committing it, I'll list them below

• Converting all libraries to SHARED

• When porting trajectory_execution_manager these commits change files outside the package

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6

• plan_execution

  • 1

• planning_scene_monitor

  • 1

• constraint_sampler_manager_loader

  • 1

The docker tags should be switched to master-ci and master-source from crystal since we do not have a crystal-devel branch. We may also want to start building off of dashing-ros-base-bionic

Copying Mike's comment from this PR

I still think that the robot_description should be able to come from either a parameter, topic, or file like the RobotModelDisplay. Just using parameters doesn't make that much sense as it requires Rviz to be launched with special arguments

I think this's the rdf_loader responsibility, we should add a new constructor for rdf_loader to do so

The MoveIt 2 demo should be moved from the main repo into moveit_tutorials, possibly as part of MoveItCpp instructions. We can still link it from the Readme.

@mlautman and @davetcoleman, can you consider labeling Pull Requests and issues accordingly?

I've been reviewing a few of the ongoing PRs and I'd love to tag them with a ToReview whereas I'd appreciate if you could tag those that you already reviewed and that need more work with such a label (e.g. NeedsWork).

To speed up the process, can you give @anasarrak and myself (@vmayoral) rights to label stuff?

We should have a fresh sync with the MoveIt master branch. I think it makes most sense to do this after we synced up with Acutronic's fork since otherwise it would be more difficult to identify the remaining progress. I'm happy to do this, @rhaschke help/feedback are appreciated ;)

I'd like to propose for MoveIt 2 we break away from the old "legacy" approach to branch naming we've been following in MoveIt 1. Our current branching strategy in MoveIt 1:

master - development branch
kinetic-devel - release branch for ROS Kinetic / 16.04
melodic-devel - release branch for ROS Melodic / 18.04

As someone with fresh eyes @jliukkonen just pointed out, we should remove the "-devel" part.

For MoveIt 2, how about something like:

master - development branch
eloquent - release branch for ROS 2 Eloquent / 18.04
foxy - release branch for ROS 2 Foxy

On top of this, we will continue to use git tags to release specific version numbers e.g. 2.1 2.2

I'm very open to other ideas - thoughts? @henningkayser @rhaschke @v4hn

Let's not close this issue until we document the decision on our website or else where.

We are a couple of master students using Moveit 2 as our motion planning framework in our master's thesis, and are having difficulties changing the planning algorithm that is used for a chosen PlanningComponent. We are using OMPL as our planning pipeline, similar to the "run_moveit_cpp" demos.

In the PlanningComponent class, we would like to have a method allowing us to specify what planner from our loaded planning_pipeline we would like to use for this particular PlanningComponent.

An alternative could be an option to change the default planner in MoveitCpp. For instance, it could be an optional parameter in the construction of the MoveitCpp instance, or a set_default_planner(...) method in the MoveitCpp class.

If there already exists ways of changing either the planner used for a particular PlanningComponent or the default planner, help finding these would be greatly appreciated.

I've given you access to our forked package dependencies which are partially migrated but still need some fixup (see warnings and upstream PRs).
https://github.com/PickNikRobotics/geometric_shapes
https://github.com/PickNikRobotics/object_recognition_msgs
https://github.com/PickNikRobotics/octomap
https://github.com/PickNikRobotics/octomap_msgs
https://github.com/PickNikRobotics/srdfdom

@RoboticsYY Could you start fixing these up and filing new PRs? That would be really helpful.

As already discussed and announced on moveit.ros.org, we're aiming for a MoveIt 2 Beta release targeting Foxy Fitzroy in July. Feature-wise, this release can be equal to the Eloquent Beta version, so the roadmap is somewhat orthogonal to the overall migration process. However, there are some changes since Eloquent that require fixing or at least should be addressed.

In particular, we should review:

• Proper use of "modern" CMake interface targets with ament_target_dependencies
• Update Node Interface getters if applicable
• Verify tests work with new working directory

Additional steps:

• Review/update rosinstall dependencies + bump release version there
• Setup docker images
• Review release status of debian dependencies -> Make update strategy
• Update Readme instructions

Usually, we would do all these steps on master and then create the release branch from it. However, this would probably interfere with the general ROS 2 migration progress, so in this case I would actually create the foxy release branch first and then merge the changes back to master after the release. Alternatively, we could continue migration on the eloquent branch and sync that progress back once Foxy support is completed.

Open questions:

Can master support Foxy and Eloquent?
Considering the required changes it seems feasible to support both versions, possibly using separate rosinstall files. However, this might not be a long-term solution as we will start adding features that make use of affected API's (subscription callbacks, node interface getters).

What's our sync strategy?
I would suggest syncing all features from master into both release branches eloquent and foxy, until both are ready for a full release (i.e. all packages are ported). Depending on master support for both versions, MoveIt 2 roadmap progress will continue targeting foxy, where changes are synced back to eloquent on a frequent basis. I don't expect too much overhead there, considering the ROS2 changes between Eloquent and Foxy.

Environment

ROS Distro: [eloquent]
OS Version: e.g. Ubuntu 18.04
Binary build
moveit2: cloned from ros-planning:moveit2:master branch at this commit.

Description

I'm porting MTC to ros2 eloquent and currently ported cartesian_position_motion.cpp as this. While building the MTC I got the error stating that the computeCartesianPath(...) function is deprecated. I can also see that the same function has been deprecated here at robot_state.h#L1058. Please suggested to me how should I proceed ahead.
Would I be able to solve this if I make appropriate modification in computeCartesianPath(...) function similar to what is been done here in Acutronic fork of moveit2?

See my full error report here.

Any help would be greatly appreciated.

We've been wanting this for a long time and I just noticed that the navigation2 project has a nice CircleCI setup we could perhaps use.

@ruffsl it looks like you were the one who spun this up for navigation, could you help us setup this up for moveit also?

In the MoveIt2 codebase, we are using / as a separator which isn't the case for ROS2, we should use . as a separator

References:

• 1
• 2

@LanderU, I see you fixed CI in https://github.com/AcutronicRobotics/moveit2/tree/master.

I started a branch at https://github.com/AcutronicRobotics/moveit2/tree/ci for making a PR once it was working (now is!). Would you like me to go ahead and cherry-pick all your changes and then submit the PR myself or would you rather like to do it yourself?

A change was made by @rhaschke in ros1/geometry2 that was not forward ported to ros2/geometry2, see ros/geometry2#335.

This change urgently needs to be ported so that there isn't a big regression in the moveit2 codebase as demonstrated here and in the related conversation: #12 (comment)

My understanding of the situation: logging in ROS2 is different than ROS1 due to the lack of a singleton (the assumption that there is one ROS node per process). In ROS2 each call to the logger requires you pass in a logger handle, or the node handle. See this discussion to get the full background.

In order to achieve the MVP of moveit2, I recommend we create the ROS2 node as a global variable, or at least the logger handle as a global variable. This will limit moveit2 from having more than one instance in the same process, but we can fix that in the future.

So, in MoveGroup main function we'll need to create this singleton.

This issue is to track the modification of logging in moveit2. @wjwwood is the lead contact for us who is expert on this issue.

Let's switch to ROS 2 Dashing as Acutronic's demonstrator already compiles and runs on it (with some fixes).

see comment here and this PR comment

Create branch (or separate repo) for MoveIt 2 tutorials and launch tutorial page. For that, all instructions need to be migrated to ROS 2 and tested for issues.

The geometric_shapes dependency (moveit2.repos) depends on eigen_stl_containers, so does the moveit_core, but this dependency is not mentioned in the .repos file

Meta-issue for tracking discussions around finishing Milestone 1 as proposed on the MoveIt 2 Migration Roadmap.

Issue proposals:

• Finish package migration (see Migration Progress Sheet) -> Create issues for remaining packages/libraries and assign to authors, are there packages that shouldn't be ported as is?
• Test/Update/Launch MoveIt 2 tutorials page (#192)
• Move run_moveit_cpp into tutorials (#193)
• Code cleanup -> review&apply ament, CMake, ROS2 best practices - document in /doc (#102)
• Setup & Structure ROS2 migration/announcements/troubleshoot documentation -> Add to /doc, publish to ROS-index, reference moveit_tutorials (#194)
• MoveIt 1 Sync strategy -> When/how to sync? Document in /doc (#45)
• Decide on release protocol -> tests, feature-syncs, ideally in accordance with MoveIt 1

See Project Board

Description

Title: Error in moveit_core while building it for the first time in workspace as
colcon build --event-handlers desktop_notification- status- --cmake-args -DCMAKE_BUILD_TYPE=Release

Environment

• ROS Distro: [eloquent]
• OS Version: e.g. Ubuntu 18.04
• Binary build
• distribution status : active
• moveit2 : cloned from ros-planning
  /moveit2(master branch) on 9/03/2020.

shapes::constructShapeFromMsg() function in conversions.cpp file expect argument of type const SolidPrimitive& {aka const shape_msgs::SolidPrimitive_<std::allocator<void> >&} but we are passing an argument of type const value_type {aka const shape_msgs::msg::SolidPrimitive_<std::allocator<void> >}, thus generating build time error as

moveit2/moveit_core/robot_state/src/conversions.cpp: In function ‘void moveit::core::{anonymous}::_msgToAttachedBody(const moveit::core::Transforms*, const AttachedCollisionObject&, moveit::core::RobotState&)’:
.../moveit_core/robot_state/src/conversions.cpp:272:84: error: no matching function for call to ‘constructShapeFromMsg(const value_type&)’
           shapes::Shape* s = shapes::constructShapeFromMsg(aco.object.primitives[i]);
                                                                                    ^
In file included from ../moveit_core/robot_state/src/conversions.cpp:39:0:
/opt/ros/melodic/include/geometric_shapes/shape_operations.h:49:8: note: candidate: shapes::Shape* shapes::constructShapeFromMsg(const SolidPrimitive&)
 Shape* constructShapeFromMsg(const shape_msgs::SolidPrimitive& shape_msg);
        ^~~~~~~~~~~~~~~~~~~~~
/opt/ros/melodic/include/geometric_shapes/shape_operations.h:49:8: note:   no known conversion for argument 1 from ‘const value_type {aka const shape_msgs::msg::SolidPrimitive_<std::allocator<void> >}’ to ‘const SolidPrimitive& {aka const shape_msgs::SolidPrimitive_<std::allocator<void> >&}’

You can see the full error msg can be found here.

I tried several to approachs to resolve this error e.g
Calling the above mentioned function like this
shapes::Shape* s = shapes::constructShapeFromMsg((const shape_msgs::msg::SolidPrimitive&)aco.object.primitives[i]);
insead of like this
shapes::Shape* s = shapes::constructShapeFromMsg(aco.object.primitives[i]);

By doing, this it generated new error as
no known conversion for argument 1 from ‘const SolidPrimitive {aka const shape_msgs::msg::SolidPrimitive_<std::allocator<void> >}’ to ‘const SolidPrimitive& {aka const shape_msgs::SolidPrimitive_<std::allocator<void> >&}’
I tried few this to resolve this too, but with no luck.

I don't know how can I resolved this issue, any help would be really appreciated.

So following the guidelines set out here, I have a really long name like the following:

static const rclcpp::Logger LOGGER = rclcpp::get_logger("moveit_move_group_default_capabilities.apply_planning_scene_service_capability");
May I suggest removing the library name requirement from that? Besides the obvious verbosity of the logging, most of the time when I search I only need the name of the cpp file.

Hardcoding relative paths is a bad idea.

I would recommend that for every library in this package that is used else ware you set a <lib_name>_lib_dir environment variable that can then be used by the tests

A good example is the rcl_lib_dir I have taken the time to show how it is used below:

/home/mike/ws_ros2/src/ros2/rcl/rcl/CMakeLists.txt:
   78  
   79: # rcl_lib_dir is passed as APPEND_LIBRARY_DIRS for each ament_add_gtest call so
   80  # the librcl that they link against is on the library path.
   81  # This is especially important on Windows.
   82  # This is overwritten each loop, but which one it points to doesn't really matter.
   83: set(rcl_lib_dir "$<TARGET_FILE_DIR:${PROJECT_NAME}>")
   84  

/home/mike/ws_ros2/src/ros2/rcl/rcl/test/CMakeLists.txt:
   16  
   17: set(extra_lib_dirs "${rcl_lib_dir}")
   18  
   
/home/mike/ws_ros2/src/ros2/rcl/rcl/test/CMakeLists.txt:
   34    rcl_add_custom_gtest(test_client${target_suffix}
   35      SRCS rcl/test_client.cpp
   36:     INCLUDE_DIRS ${osrf_testing_tools_cpp_INCLUDE_DIRS}
   37      ENV ${rmw_implementation_env_var}
   38      APPEND_LIBRARY_DIRS ${extra_lib_dirs}

The example uses rcl_add_custom_gtest but it works just as well with ament_add_gtest

@ahcorde

Environment

ROS Distro: [eloquent]
OS Version: e.g. Ubuntu 18.04
Binary build
distribution status: active
moveit2: cloned from ros-planning:moveit2:master branch at this state.

Description

I got No matching function error for PlanningPipeline() while I was trying to port move_group to eloquent as:

--- stderr: moveit_ros_move_group                                                                                            
/home/rajendra/ros2eloquent_moveit_ws/src/moveit2/moveit_ros/move_group/src/move_group_context.cpp: In constructor ‘move_group::MoveGroupContext::MoveGroupContext(const PlanningSceneMonitorPtr&, std::shared_ptr<rclcpp::Node>&, bool, bool)’:
/home/rajendra/ros2eloquent_moveit_ws/src/moveit2/moveit_ros/move_group/src/move_group_context.cpp:52:114: error: no matching function for call to ‘planning_pipeline::PlanningPipeline::PlanningPipeline(const RobotModelConstPtr&, std::shared_ptr<rclcpp::Node>&)’
   planning_pipeline_.reset(new planning_pipeline::PlanningPipeline(planning_scene_monitor_->getRobotModel(), node));
                                                                                                                  ^
In file included from /home/rajendra/ros2eloquent_moveit_ws/src/moveit2/moveit_ros/move_group/src/move_group_context.cpp:39:0:
/home/rajendra/ros2eloquent_moveit_ws/install/moveit_ros_planning/include/moveit/planning_pipeline/planning_pipeline.h:94:3: note: candidate: planning_pipeline::PlanningPipeline::PlanningPipeline(const RobotModelConstPtr&, std::shared_ptr<rclcpp::Node>, const string&, const string&, const std::vector<std::__cxx11::basic_string<char> >&)
   PlanningPipeline(const robot_model::RobotModelConstPtr& model, const std::shared_ptr<rclcpp::Node> node,
   ^~~~~~~~~~~~~~~~
/home/rajendra/ros2eloquent_moveit_ws/install/moveit_ros_planning/include/moveit/planning_pipeline/planning_pipeline.h:94:3: note:   candidate expects 5 arguments, 2 provided
/home/rajendra/ros2eloquent_moveit_ws/install/moveit_ros_planning/include/moveit/planning_pipeline/planning_pipeline.h:81:3: note: candidate: planning_pipeline::PlanningPipeline::PlanningPipeline(const RobotModelConstPtr&, std::shared_ptr<rclcpp::Node>, const string&, const string&, const string&)
   PlanningPipeline(const robot_model::RobotModelConstPtr& model, const std::shared_ptr<rclcpp::Node> node,

Step to reproduce the error

1. Replace the ros-planning:moveit2:master:move_group with AcutronicRobotics:moveit2:master:move_group.
2. Build using colcon build
3. Encounter moveit_move_group_capabilities_base dependency error(see here) so I commented this line to resolve error(can it be the reason for no matching function error?).
4. Then build again.
5. Got No matching function error for functions like PlanningPipeline, TrajectoryExecutionManager, PlanWithSensing etc and other type conversion error. See full error here.

I tried changing the definition of a function with no success. Moreover, I can see that even in moveit1 these functions were defined in the same manner but It doesn't produce error there. I also have ros:melodic:moveit install in a separate workspace along with this ros:eloquent:moveit2 and I can confirm that there is no intermixing in the environment this time as it was there in last time.

Any help would be greatly appreciated.

There are several packages already ported in Acutronic's fork which allows to run a first demo (https://discourse.ros.org/t/moveit-2-journey-first-demonstrator-in-ros-2-planning-to-a-joint-space-goal/9301). In order to sync the progress @JafarAbdi will create PRs for all package that has been ported but not yet merged into ros-planning. We can then decide on an individual basis what changes we adopt and how we proceed.

Description

When building moveit2 for ROS 2 eloquent, the build fails at the moveit_ros package, specifically when building the planning_request_adapter_plugins in the planning sub-directory. The build fails because the default_planner_request_adapters::ResolveConstraintFrame class implementation (located at moveit_ros/planning/planning_request_adapter_plugins/src/resolve_constrant_frames.cpp) references the resolveConstraintFrames() function in the moveit::kinematics_constrant namespace, but said function has been commented out for a while. The comment block just above the function implementation in the moveit_core/kinematics_constrant/utils.cpp file hinted at the function not being used anywhere, despite its use in default_planner_request_adapters::ResolveConstraintFrames. The function declaration, however, was not commented out.

An article published around February this year hinted at plugin functionality not being available, and given the name of the subdirectory containing the broken file (planning_request_adapter_plugins), I wonder if that's a directory that must be excluded from the build.

Your environment

• ROS Distro: Eloquent (ROS2)
• OS Version: macOS 10.13.6
• Source or Binary build? Source Build
• If binary, which release version? N/A
• If source, which branch? master

Steps to reproduce

1. Install and build ROS 2 eloquent from source, along with any required dependencies.
2. Create a "workspace" directory as the root of the ROS 2 tree for MoveIt! 2 (e.g., moveit2_ws)
3. Clone ros-planning/moveit2 onto a src folder under the aforementioned "workspace" folder.
4. Do a colcon build --symlink-install from the root of the ROS 2 tree.

Expected behaviour

Packages should build and install under the ROS 2 tree in the install/ subfolder.

Actual behaviour

After successfully building moveit_core, moveit_msgs, moveit_resources, moveit_simple_controller_manager (not necessarily in that order, and not explicitly listing pre-requisites), build fails at moveit_ros_planning.

Backtrace or Console output

Abbreviated build output follows:

Undefined symbols for architecture x86_64:
  "kinematic_constraints::resolveConstraintFrames(moveit::core::RobotState const&, moveit_msgs::msg::Constraints_<std::__1::allocator<void> >&)", referenced from:
      default_planner_request_adapters::ResolveConstraintFrames::adaptAndPlan(boost::function<bool (std::__1::shared_ptr<planning_scene::PlanningScene const> const&, moveit_msgs::msg::MotionPlanRequest_<std::__1::allocator<void> > const&, planning_interface::MotionPlanResponse&)> const&, std::__1::shared_ptr<planning_scene::PlanningScene const> const&, moveit_msgs::msg::MotionPlanRequest_<std::__1::allocator<void> > const&, planning_interface::MotionPlanResponse&, std::__1::vector<unsigned long, std::__1::allocator<unsigned long> >&) const in resolve_constraint_frames.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[2]: *** [planning_request_adapter_plugins/CMakeFiles/moveit_default_planning_request_adapter_plugins.dir/build.make:393: planning_request_adapter_plugins/libmoveit_default_planning_request_adapter_plugins..dylib] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:565: planning_request_adapter_plugins/CMakeFiles/moveit_default_planning_request_adapter_plugins.dir/all] Error 2

See this nifty tutorial:
https://ubuntu.com/blog/how-to-add-a-linter-to-ros-2

Description

From joint_limits parameters:

Looking At robot_model_loader.cpp,
it attempts to joint_limits "max_position" and "min_position" from parameters, but only when the robot_description parameter path is present in rdf_loader.
However, the current rdl_loader can never have the robot_description variable. It's never set in rdf_loader's code under any circumstance.
(URDF is provided as a string anyway, so robot_description parameter doesn't make sense.)

From URDF:

For instance, a joint has:
<limit effort="1000" lower="0.0" upper="1.13446401394" velocity="6.5"/>

Velocity limits are loaded, but the position limits are not. eg. I get when I print my robot model

P.unbounded [-3.14159, 3.14159]; V.bounded [-6.50000, 6.50000]; A.unbounded [0.00000, 0.00000];

(I've verified the limits are loaded correctly by urdf_parser and that they are just never copied RobotModel's limits)

In addition, I have tried setting them programatically through setVariableBounds on JointModels,
but I'm only able to get a const pointer for the robot model and subsequently joint models.

Your environment

• ROS Distro: Eloquent
  OS Version: e.g. Ubuntu 18.04
• Source or Binary build? Source (Master Branch)

Steps to reproduce

Load any robot model

Expected behaviour

Position Limits are loaded

Actual behaviour

Position limits can not be loaded.

Evironment: windows10 eloquent.
when I failed to build, I can't serach the instructions on windows.
c:\ws>colcon build --merge-install
Starting >>> object_recognition_msgs
Starting >>> octomap_msgs
Starting >>> random_numbers
Starting >>> urdfdom_py
Starting >>> joint_state_publisher
Starting >>> ompl
Starting >>> turtlesim
Finished <<< urdfdom_py [2.09s]
Starting >>> srdfdom
Finished <<< joint_state_publisher [2.25s]
Starting >>> moveit_resources
Starting >>> joint_state_publisher_gui
Finished <<< joint_state_publisher_gui [2.59s]
Finished <<< moveit_resources [12.6s]
Failed <<< random_numbers [ Exited with code 1 ]
Aborted <<< srdfdom
Aborted <<< octomap_msgs
Aborted <<< ompl
Aborted <<< turtlesim
Aborted <<< object_recognition_msgs

Summary: 4 packages finished [34.0s]
1 package failed: random_numbers
5 packages aborted: object_recognition_msgs octomap_msgs ompl srdfdom turtlesim
5 packages had stderr output: object_recognition_msgs octomap_msgs ompl srdfdom turtlesim
11 packages not processed

Description

In loading the config yaml files for MoveItCPP in my application,
an incorrect yaml type error is thrown when parsing the ompl_planning.yaml file

Overview of your issue here.
I don't have a screen capture of the actual error message but it seemed to suggest that it expected a string but got a double instead. I was able to get it to accept the yaml file by placing quotes around the value assigned to longest_valid_segment_fraction field in order to make it a string, see here

Your environment

• ROS Distro: [Eloquent]
• OS Version: e.g. Ubuntu 18.04
• Source
• master branch

Steps to reproduce

Load ompl_planning.yaml file which includes the longest_valid_segment_fraction set to a double

Expected behaviour

MoveItCPP should load the yaml file and configure itself from it

Actual behaviour

Throws exception saying that it expected a string but got a double instead

Backtrace or Console output

Did't capture :(

• Should be built on top of OSRF's ROS2 docker containers.
• Is hosted at: https://cloud.docker.com/u/moveit/repository/docker/moveit/moveit2

General (non-technical) cleanup steps and linting tools for better consistency in the code and maintainability.

TODOs

• ament_lint, clang-tidy-fix (#210)
• Unify logging, apply logger name conventions across codebase
• Use RCL_ROS_TIME where applicable
• Remove redundant meta packages
• Update documentation, cleanup ROS 1 references (i.e. NodeHandle, parameter server... )
• Remove commented and deprecated code, outdated TODO's

Old description:

In order enforce clean coding standards using clang-format, clang-tidy (others?) we should enable ament-lint for all packages (https://github.com/ament/ament_lint).

Related/duplicate with #98. (https://ubuntu.com/blog/how-to-add-a-linter-to-ros-2)

While on the porting procedure, there are different ros::Time / ros::Walltime calls that have to be subtituted by rclcpp time calls.

The problem is that there is no similar call for ros::Walltime on ros2, I've found that the rclcpp has a member called WallTimer, but it has nothing to do with ros:Walltime.

Right now I'm replacing them with rclcpp::Time, but I would like some input about that, also I would like to know why sometimes Walltime is used instead of Time .

Create one or several PRs that apply the same conversions from Catkin to Ament across all moveit repo-based MoveIt packages. Here's a relevant debate on how to do this for moveit2

One suggested approach, 2

Description

When running:

colcon build --event-handlers desktop_notification- status- --cmake-args -DCMAKE_BUILD_TYPE=Release

I get:

--- stderr: moveit_ros_occupancy_map_monitor
CMake Error at /home/andyz/ws_ros2/install/moveit_core/share/moveit_core/cmake/ament_cmake_export_libraries-extras.cmake:48 (message):
  Package 'moveit_core' exports the library 'moveit_exceptions' which
  couldn't be found

Your environment

• ROS Distro: Eloquent, binary installation
• OS Version: Ubuntu 18.04
• Building moveit2 from source (master branch)
• I've triple-checked that I'm sourcing install/setup.bash
• I ran:
  rosdep install --from-paths src --ignore-src --rosdistro eloquent -y --skip-keys "console_bridge fastcdr fastrtps libopensplice67 libopensplice69 rti-connext-dds-5.3.1 urdfdom_headers"
• Also tried:
  rosdep install -r --from-paths . --ignore-src --rosdistro eloquent -y

We should structure and expand our internal ROS2-related documentation.
Currently, we have a simple migration guideline inside /doc. I think we should add more instructions and information regarding migration steps, troubleshooting, release information, etc... All these should still be accessible from the Readme and ideally also from the ROS-index.

Some example sections:

• Releases (Eloquent, Foxy), Changelogs, Features
  • Release process, Sync process, branches
  • Roadmap
• Migration MoveIt 1 -> MoveIt 2
  • Developer
  • User
• Known issues / Troubleshooting
• Related projects

Of course there is some potential overlap with the MoveIt website or moveit_tutorials, but I would like to get a discussion started how we should compile all that information in one place without a lot of overhead.

Moving @rhaschke 's documentation and proposal here for further debate.

@rhaschke :

In contrast to the merge-strategy suggested in #26 (comment), I propose the following for the future:

git clone https://github.com/ros-planning/moveit2
cd moveit2
git fetch https://github.com/ros-planning/moveit master  # fetch MoveIt 1 branch
git merge FETCH_HEAD  # and merge into MoveIt 2 head

If approved, such a sync PR should be "merged" manually using fast-forward. github's web interface doesn't provide such an option!
Using github's merge commit, will create another, superfluous commit and squashing or rebasing doesn't make sense at all.
However, looks like @davetcoleman has forbidden to push to the MoveIt 2 repo from cmdline. This is a typical use case, where interaction from cmdline is desirable 😉

When there are no merge conflicts, the following procedure using github's web interface will work too:

git clone https://github.com/ros-planning/moveit2
cd moveit2
git fetch https://github.com/ros-planning/moveit master  # fetch MoveIt 1 branch
git checkout -b melodic-sync FETCH_HEAD  # check it out as branch melodic-sync
git push origin melodic-sync  # push to file a PR

Subsequently, file a PR for the created melodic-sync branch and merge using a standard merge-commit.