How to connect the MoveIt! planning with Gazebo simulation
I am copying my question from the answers.gazebosim.org forum here, because I'm not sure to which forum this better suits.
I am trying for several days to achieve a connection between MoveIt! and Gazebo. I tried to follow various tutorials and find the right usage in other people repositories. I wasn't able to get to a working prototype and I run out of options what to try.
My current code is in this repository: https://github.com/kkumpa/ros-robotic...
How I got to this code:
- I have build a robot model in URDF format. The robot consists of two moving joints. (robotic_arm_description)
- Following this tutorial, I have used the MoveIt! Setup Assistant 2.0 to generate moveit config files. (robotic_arm_moveit_config)
- I clicked "Generate Collision Matrix" in the Self-Collisions tab. I didn't uncheck anything. Left it as it was generated.
- I added a virtual joint in the Virtual Joints tab. I don't know what is this good for. I saw it in one of the tutorial. I don't know what should be the parent frame and the child link.
- I added the planning group consisting of the two revolute joints and the fixed joint fixing the long arm to the second revolute joint. And a planning group containing the end effector link.
- I added some robot poses
- I set the end
effector_linkas the end effector in the End Effectors tab. - I have created the
forearm_position_controllerset asposition_controllers/JointTrajectoryController(that is the type of the joints in the group) and assigned to it the forearm planning group (two revolute joints and one fixed) - And I have generated the files.
- I have followed this tutorial to set the Gazebo part of the package.
- Created the
controllers.yaml - My
robotic_arm_moveit_config/launch/robotic_arm_moveit_controller_manager.launch.xmlalready had some content which was almost the same to what the tutorial said to write into it, so I rewrite the one different name (ros_controllers.yaml to controllers.yaml) - uncommented the octomap_frame parameter in the
robotic_arm_moveit_config/launch/sensor_manager.launch.xmlfile and set the frame tomap. - Created a new
config/robotic_arm_control.yamlandlaunch/robotic_arm_control.launchfiles in the robot control package.
- Created the
When I run the gazebo simulation using roslaunch robotic_arm_gazebo empty_world.launch command and run the rviz using the roslaunch robotic_arm_moveit_config moveit_planning_execution.launch command, I can find the predefined positions in the planning manager in rviz and plan the movement from one to another, but when I click 'execute', the robotic arm in Gazebo doesn't move. Not even the arm inside Gazebo changes it's initial position. When I apply a force on some of the robot arm links in gazebo, the controller just keeps the pose in initial position.
I have toyed with other people's robotic arm, there the behavior of the arm in gazebo was such, that without the rviz the robotic arm falls to the ground and when you open rviz, the pose of the robotic arm in the rviz corresponds to the ...
Related: #q293459.
Why did you delete this question?
@gvdhoorn Because I have solved it and decided the question is more relevant to the gazebosim forum, where I posted the answer and accepted it. I didn't want to have two same questions with virtually the same contribution at two forums. I didn't find your comment valuable enough to keep this question on the forum. It speaks just of the terminology of "connecting the MoveIt with Gazebo", right? Which I think is not totally wrong, because in the end each node does connect to each other node to which topics it subscribes/publishes. The subscribe-publish analogy is just simplification of what actually happens under the hood, right?
If you've solved it over at Gazebo Answers, then please post a link here to that question in an answer. Just accept your own answer.
I'm not sure what you mean by this, but in any case: no, pub-sub is actually used in all of this. It's not an analogy.
@gvdhoorn I know we should't talk about it here, but in the same time I want to react. What I mean is the fact, that when you launch a node that, say, publishes to a topic, the ROS master takes a note of it. Then you launch a node that subscribes to the same topic. So the ROS master acknowledges those two nodes about each other and they make a connection. Then they can send messages between each other. If there is no node to listen, there is no message transferred to anywhere, because there is no connection between two nodes. There is no 'topic buffer' that exists outside any specific node-node connection, as it is visualized here, forexample. But more like how it is visualized here.
I'm still not really sure how what you just wrote connects to your question, or to #q293459.
In any case: the diagram on the Mathworks site does not necessarily imply there is a "topic buffer". It just uses a rectangular box to group some info on a topic (ie: name and type). It's just a "boxes-and-arrows" diagram.
@gvdhoorn no no, this was more to explain why the #q293459 is not useful for this question. There was completely different problem in my case. Therefor I decided to delete this question as there was no comment of any value to this topic, from my perspective. If you are something like an administrator, you can delete this whole thread about deleting the question. It should be correct now.