After reading the previous section of Rviz and Gazebo joint simulation movement (1), I believe that the friends can successfully export the xxx_moveit_config planning package, but it is estimated that it cannot be used. There are some parameters that need to be set, especially some pits that need special attention , the purpose of this blog post is to elaborate on how to use the exported planning feature pack .
Digression : Here is a little digression, which is about what a virtual joint grasping_frame in the previous section Rviz and Gazebo joint simulation motion (1) is used for . The details are as follows:
First, where exactly is this virtual joint? look at the picture below
This grasping_frame virtual joint is set between the two grippers , and this joint will be used later in the simulated grabbing---very important . Some friends will ask? Why don't you export it together when exporting URDF? Good question! As I said before, grasping_frame is just a virtual joint and does not contain any entities , so URDF cannot be exported, and it can only be added and modified manually after the file is generated later .
Modify as follows:
<link name="grasping_frame"/>
<joint name="grasping_frame_joint" type="fixed">
<parent link="link6"/>
<child link="grasping_frame"/>
<origin xyz="0 -0.04149 0.36965" rpy="0 -1.5708 -3.14"/>
</joint>The parent of the grasping_frame joint is link6, so the position is equivalent to the distance and rotation angle of coordinate6. This distance is the y-axis translation -0.04149, and the z-axis is 0.36965. There is a saying about the rotation, which is the order of internal rotation zyx. The coordinate axis coordinate6 first revolves Looking at its own z-axis, the eyes follow the direction of the arrow counterclockwise by π, and then around their own y-axis counterclockwise by π/2. For verification, look at the picture above and try to think for yourself.
How to use this virtual joint ? look at the picture below
Did you suddenly understand the benefits of this virtual joint? I set the grab point and grab pose at the position of the two handles of the target object, and move the virtual joint grasping_frame to this position to complete a grab. So this joint is very important.
Stop talking nonsense, let's get to the point:
I believe that the friends can successfully export the following planning function package ----xxx_moveit_config
This function package looks like this:
There are some relevant parameters in the config package, and the corresponding running files in the launch. The structure is very simple, so how do we modify it? as follows
Modify step 1:
First modify the urdf file automatically generated by the moveit configuration assistant . I mentioned the following content in a module of the Rviz and Gazebo joint simulation movement (1) in the previous section: Do you want everyone to click on the simulation module to automatically generate a name called robot2600_20_text.urdf file and paste the content into it? That's right! modify it first
Please read the content carefully, the configuration assistant automatically added two pieces of duplicate content for us , so we have to delete the content we added, what does that mean? look at the picture below
The first piece of content that is automatically added is the transmission tag
The content in the above picture was manually added when we first modified it into an xacro file, but the configuration assistant added this content for us, so it was repeated ------- let's delete what we wrote and use the assistant automatically added . ----Look carefully here, some of the content added by the configuration assistant is not hardware_interface/PositionJointInterface, we need to modify it to this type. Look carefully ha!
The second piece of content that is automatically added is
In this part, we also delete what we added, and use the assistant to automatically generate it ! Why are they all automatically generated? Because the system is more rigorous than ours.
Pit: Mention the pits you will encounter here
The first pitfall: Some of the transmission tags added by the configuration assistant are not hardware_interface/PositionJointInterface .
The second pitfall: the second piece of content automatically added by the assistant has a tag of <robotNamespace>/</robotNamespace>, you can see that I only wrote a "/" backslash, please don't write your own robotic arm in it For the name , just write a backslash, why! Sometimes if I am negligent, I will write the name of the robotic arm wrong, which will cause a mismatch, and an error will be reported when it runs later.
The third pitfall: I heard that when some small partners automatically generate the content of the second block in the above picture is incomplete, that is, the plugin tag is incomplete, I heard that there is! Anyway, I'm complete, everyone check it out! My picture above is complete.
Modify step 2:
Click to open the xxx_moveit_config function package--launch folder--gazebo.launch file in turn, there is a section of this path content in it,
This is the urdf path, put the modified robot2600_20_text.urdf path into it, mine is not called this name, mine is called robot2600_20_allin.urdf, so please modify this path and change it to your own!
At this time, you can run the gazebo.launch file alone, and it works! But can't plan! (remember to compile)
Modification step 3: ( core modification )
Open the xxx_moveit_config function package--config folder--ros_controllers.yaml file in turn, and use the arm_position and gripper_position of position_controllers/JointTrajectoryController to replace the xxx_controller in the controller_list whose type is FollowJointTrajectory , as shown below!
Is it difficult to understand? Let's put it this way! One of the type FollowJointTrajectory and the type position_controllers/JointTrajectoryController is to send planning messages, and the other is to receive planning messages , so their two names must be the same and correspond, otherwise they cannot receive ! It took a long time to solve this pit at the beginning, and I couldn’t find a solution on the Internet, and people who reported the error collapsed !
You may ask, this part looks familiar! Isn't there one of the modules in the planning assistant? That's right, adding a control module! This is the most bloody thing . You can’t add the same name with the configuration assistant , so when the previous article explained this, people were exhausted.
Post the complete code as follows:
# Simulation settings for using moveit_sim_controllers
moveit_sim_hw_interface:
joint_model_group: robot2600_arm
joint_model_group_pose: home
# Settings for ros_control_boilerplate control loop
generic_hw_control_loop:
loop_hz: 300
cycle_time_error_threshold: 0.01
# Settings for ros_control hardware interface
hardware_interface:
joints:
- joint1
- joint2
- joint3
- joint4
- joint5
- joint6
- gripper_finger_joint_right
sim_control_mode: 1 # 0: position, 1: velocity
# Publish all joint states
# Creates the /joint_states topic necessary in ROS
joint_state_controller:
type: joint_state_controller/JointStateController
publish_rate: 50
controller_list:
- name: arm_position
action_ns: follow_joint_trajectory
default: True
type: FollowJointTrajectory
joints:
- joint1
- joint2
- joint3
- joint4
- joint5
- joint6
- name: gripper_position
action_ns: follow_joint_trajectory
default: True
type: FollowJointTrajectory
joints:
- gripper_finger_joint_right
arm_position:
type: position_controllers/JointTrajectoryController
joints:
- joint1
- joint2
- joint3
- joint4
- joint5
- joint6
gains:
joint1:
p: 100
d: 10
i: 0.01
i_clamp: 1
joint2:
p: 100
d: 10
i: 0.01
i_clamp: 1
joint3:
p: 100
d: 10
i: 0.01
i_clamp: 1
joint4:
p: 100
d: 10
i: 0.01
i_clamp: 1
joint5:
p: 100
d: 10
i: 0.01
i_clamp: 1
joint6:
p: 100
d: 10
i: 0.01
i_clamp: 1
gripper_position:
type: position_controllers/JointTrajectoryController
joints:
- gripper_finger_joint_right
gains:
gripper_finger_joint_right:
p: 100
d: 10
i: 0.01
i_clamp: 1The above is the core modification:
There is a pit here :
Observe all the joints carefully: there is a "-" in front of each joint, and there is a horizontal line. This is really convincing. The joint in the automatically generated gripper_position does not have this horizontal line at the beginning. You must carefully observe this file For all the joints in it, you must add this horizontal line, otherwise there will be an error that the joint is not an array! -------This really left me speechless
Last Review:
Click to open the xxx_moveit_config function package--launch folder--demo_gazebo.launch file. This file is the main file we use for planning !
Friends may ask, isn't this a demo? yes! The configuration assistant automatically wrote an available demo for us, we can use it directly. There may be someone who wrote a similar startup file by hand . For example, Gu Yueju wrote one by himself, which is actually the same . When you open this demo_gazebo.launch, you will find that the content is similar to that of Gu Yueju. We don’t have to bother to write it ourselves, and we can use the damo_gazebo.launch file as Gu Yueju’s handwritten startup file in the future.
Modifying this file is very simple, first modify the urdf address ! You can make the same modification as in the second step . I haven't modified it here yet, I want to modify it!
Then look at the rviz loading node inside:
I am also speechless here?
If you don't comment it out, then you only modify to the previous step. In fact, all the modifications have been completed. Compile and run the damo_gazebo.launch file and you can already perform motion planning, but you will be surprised to find that gazebo progresses from time to time. Die, and then all processes are stuck! You will never find a solution online, absolutely!
So what is the correct way to start ? After the rviz comments are done first, then all modifications are done, and then compile!
First of all, open the terminal and run killall gzserver and killall gzclient respectively. What do these two sentences mean? It is to kill the last gazebo process, and run this every time you want to run gazebo, so as to prevent the gazebo process from dying
Second : run the demo_gazebo.launch file, the following interface will appear:
When the message "you can start planning now" appears, congratulations, you can start planning. At this time, there is only the gazebo interface.
Open a terminal separately, enter rviz and press Enter
Fixed Frame select base_link, then click add in the lower left corner to add the MotionPlanning module
After adding the MotionPlanning module, the following interface will appear. After you drag the planning ball to give the robotic arm a pose, click Plan & Execute to plan and execute. You will see that the robotic arm has planned the trajectory in rviz, and you can go to Gazebo to find , the robotic arm in Gazebo also moves
After reading this far, congratulations, the problem of joint motion planning has been completely solved. It's not easy! I should have pointed out many of the pitfalls to everyone, and they were summed up after a lot of research and information, and they are absolutely effective!
Digression:
There are almost only these contents in joint motion planning. Later, because the blogger is doing 3D point cloud and mechanical arm collision avoidance, he does not do motion planning algorithms . Many people do motion planning algorithms, and there are many excellent blogs. The following will only involve 3D point cloud registration, collision avoidance, octree, generation of obstacles, collision-free capture, etc., and there will be no motion planning content. I don't know what to update!