moveit / moveit2 Goto Github PK
View Code? Open in Web Editor NEW:robot: MoveIt for ROS 2
Home Page: https://moveit.ai/
License: BSD 3-Clause "New" or "Revised" License
:robot: MoveIt for ROS 2
Home Page: https://moveit.ai/
License: BSD 3-Clause "New" or "Revised" License
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
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.
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.
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
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?
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.
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.
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.
Load any robot model
Position Limits are loaded
Position limits can not be loaded.
@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?
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.
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.
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,
colcon build
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?).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.
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
Package name | Package name | Package name | PR opened | PR merged | Notes |
---|---|---|---|---|---|
moveit_ros | ◻️ | ◻️ | |||
planning | ◻️ | ◻️ | |||
robot_model_loader | ✔️ | ✔️ | |||
trajectory_execution_manager | ✔️ | ◻️ | |||
planning_request_adapter_plugins | ✔️ | ✔️ | |||
constraint_sampler_manager_loader | ✔️ | ✔️ | |||
rdf_loader | ✔️ | ✔️ | |||
planning_pipeline | ✔️ | ✔️ | |||
plan_execution | ✔️ | ◻️ | |||
kinematics_plugin_loader | ✔️ | ✔️ | |||
planning_components_tools | ✔️ | ✔️ | No progress made for porting | ||
collision_plugin_loader | ✔️ | ◻️ | |||
planning_scene_monitor | ✔️ | ◻️ | |||
benchmarks | ✔️ | ✔️ | No progress made for porting | ||
manipulation | ◻️ | ◻️ | |||
move_group | ◻️ | ◻️ | |||
perception | ✔️ | ✔️ | No progress made for porting | ||
planning_interface | ◻️ | ◻️ | |||
py_bindings_tools | ◻️ | ◻️ | |||
common_planning_interface_objects | ◻️ | ◻️ | |||
planning_scene_interface | ◻️ | ◻️ | |||
move_group_interface | ◻️ | ◻️ | |||
robot_interface | ◻️ | ◻️ | |||
test | ◻️ | ◻️ | |||
robot_interaction | ◻️ | ◻️ | |||
visualization | ◻️ | ◻️ | |||
warehouse | ◻️ | ◻️ | |||
moveit_core | ✔️ | ✔️ | |||
moveit_experimental | ✔️ | ✔️ | No progress made for porting | ||
moveit_kinematics | ◻️ | ◻️ | |||
cached_ik_kinematics_plugin | ✔️ | ✔️ | No progress made for porting | ||
ikfast_kinematics_plugin | ✔️ | ✔️ | No progress made for porting | ||
kdl_kinematics_plugin | ◻️ | ◻️ | |||
lma_kinematics_plugin | ◻️ | ◻️ | |||
srv_kinematics_plugin | ◻️ | ◻️ | |||
test | ◻️ | ◻️ | |||
moveit_planners | ◻️ | ◻️ | |||
chomp | ✔️ | ✔️ | No progress made for porting | ||
ompl | ◻️ | ◻️ | |||
sbpl | ✔️ | ✔️ | No progress made for porting | ||
moveit_plugins | ◻️ | ◻️ | |||
moveit_controller_manager_example | ✔️ | ✔️ | No progress made for porting | ||
moveit_ros_control_interface | ✔️ | ✔️ | No progress made for porting | ||
moveit_fake_controller_manager | ◻️ | ◻️ | |||
moveit_simple_controller_manager | ◻️ | ◻️ | |||
moveit_setup_assistant | ✔️ | ✔️ | No progress made for porting |
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
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?
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
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 ;)
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:
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.
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
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
Load ompl_planning.yaml file which includes the longest_valid_segment_fraction
set to a double
MoveItCPP should load the yaml file and configure itself from it
Throws exception saying that it expected a string but got a double instead
Did't capture :(
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.
Meta-issue for tracking discussions around finishing Milestone 1 as proposed on the MoveIt 2 Migration Roadmap.
Issue proposals:
run_moveit_cpp
into tutorials (#193)/doc
(#102)/doc
, publish to ROS-index, reference moveit_tutorials (#194)/doc
(#45)See Project Board
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.
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
The image that is using for the CI is outdated and is failing because of changes in the key.
Error:
I you rebuild the image solves the issue: https://discourse.ros.org/t/key-rotation-for-ros-2-apt-repositories/9363
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
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.
ROS Distro: [eloquent]
OS Version: e.g. Ubuntu 18.04
Binary build
moveit2: cloned from ros-planning:moveit2:master branch at this commit.
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.
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)
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.
master
moveit2_ws
)ros-planning/moveit2
onto a src
folder under the aforementioned "workspace" folder.colcon build --symlink-install
from the root of the ROS 2 tree.Packages should build and install under the ROS 2 tree in the install/
subfolder.
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
.
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
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
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.
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 .
See this nifty tutorial:
https://ubuntu.com/blog/how-to-add-a-linter-to-ros-2
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.
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?
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.
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
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"
rosdep install -r --from-paths . --ignore-src --rosdistro eloquent -y
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)
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
Build should finish without errors
Build errors out with the error message shown above
General (non-technical) cleanup steps and linting tools for better consistency in the code and maintainability.
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)
Moving @rhaschke 's documentation and proposal here for further debate.
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.
Let's switch to ROS 2 Dashing as Acutronic's demonstrator already compiles and runs on it (with some fixes).
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?
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:
ament_target_dependencies
Additional steps:
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.
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.
/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....
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.