In the previous tutorial, you learned how to leverage ROS 2 Control to move the robotic arm manually by sending raw joint commands to the robot. This exercise is great for learning, but it is not how things are done in a real-world robotics project.
In this tutorial, I will show you how to set up a ROS 2 software called MoveIt 2 to send those commands. MoveIt 2 is a powerful and flexible motion planning framework for robotic manipulators.
Using MoveIt 2 instead of sending manual commands through a terminal window allows for more sophisticated, efficient, and safer motion planning, taking into account obstacles, joint limits, and other constraints automatically.
By the end of this tutorial, you will be able to create this:
Prerequisites
- You have completed this tutorial: Create and Visualize a Robotic Arm with URDF – ROS 2 Jazzy
All my code for this project is located here on GitHub.
How MoveIt 2 Works with ROS 2 Control
Before we dive into the tutorial, let me explain how MoveIt 2 works with ROS 2 Control by walking through a common real-world use case.
Suppose you have a mobile manipulator, which consists of a wheeled robot base with a robotic arm attached to it.
You want to develop an application that performs a pick and place task.
Your cool app starts by telling MoveIt 2, “Pick up the object at location A and place it at location B.”
MoveIt 2, with help from Nav 2 (the navigation software stack for ROS 2), plans out the detailed movements needed – reaching for the object, grasping it, lifting it, moving to the new location, and placing it down.
These plans are sent to ROS 2 Control’s Controller Management system, which has specific controllers for the arm, gripper, and base.
The arm controller (e.g. JointTrajectoryController), for example, breaks down the plan into specific joint movements and sends these to the Resource Management system.
The Resource Management system communicates these commands through hardware interfaces to the actual robot parts (or their simulated versions).
As the robot executes the pick and place task, sensors in its joints and gripper send back information about position, force, and status.
This feedback flows back up through the system, allowing your app and MoveIt 2 to monitor progress and make adjustments if needed.
This setup allows you to focus on defining high-level tasks while MoveIt 2 and ROS 2 Control handle the complex details of robot control and movement coordination.
Now let’s look at another diagram which shows the specific controller and topic names. This gives us a more detailed view of how MoveIt 2, ROS 2 Control, and the robot components interact:
Your cool application initiates the process, defining tasks like pick and place operations.
MoveIt 2 contains a path planning component that generates trajectory commands. These commands are sent to the Joint Trajectory Controller, which manages the arm’s movements.
For mobile robots, Nav 2 can send twist commands to the Diff Drive Controller, controlling the base’s motion.
The system includes several specialized controllers:
- Joint Trajectory Controller for arm movements
- Forward Velocity Controller for speed control (optional…only needed if you need direct velocity control for high-speed operations)
- Gripper Controller for end-effector actions (e.g. open and close gripper)
- Diff Drive Controller for mobile base navigation
These controllers communicate with Hardware Interfaces for the arm, gripper, mobile base, and the Gazebo simulation.
As the robot operates, sensor data flows back through these Hardware Interfaces. This information includes position, velocity, force, and status updates.
The Joint State Broadcaster and Force Torque State Broadcaster collect this feedback data.
This state information (e.g. joint angles) is then forwarded to RViz for visualization and to MoveIt 2 for real-time monitoring and adjustment.
Update package.xml
Now that you understand how all the pieces work together on a high level, let’s start setting up our robot with MoveIt 2.
Create a new package called mycobot_moveit_config:
cd ~/ros2_ws/src/mycobot_ros2/mycobot_moveit_configYour package.xml should look like this:
<?xml version="1.0"?>
<?xml-model href="http://download.ros.org/schema/package_format3.xsd" schematypens="http://www.w3.org/2001/XMLSchema"?>
<package format="3">
<name>mycobot_moveit_config</name>
<version>0.0.0</version>
<description>MoveIt configuration, launch files, and SRDF files for myCobot robots</description>
<maintainer email="automaticaddison@todo.com">ubuntu</maintainer>
<license>BSD-3-Clause</license>
<buildtool_depend>ament_cmake</buildtool_depend>
<depend>moveit_ros_planning_interface</depend>
<depend>moveit_ros_move_group</depend>
<depend>moveit_kinematics</depend>
<depend>moveit_planners_ompl</depend>
<depend>moveit_ros_visualization</depend>
<depend>rviz2</depend>
<depend>rviz_visual_tools</depend>
<exec_depend>moveit_simple_controller_manager</exec_depend>
<exec_depend>moveit_configs_utils</exec_depend>
<exec_depend>pilz_industrial_motion_planner</exec_depend>
<test_depend>ament_lint_auto</test_depend>
<test_depend>ament_lint_common</test_depend>
<export>
<build_type>ament_cmake</build_type>
</export>
</package>
Save the file, and close it.
cd ~/ros2_ws/rosdep install --from-paths src --ignore-src -r -yType in your password, and install any missing dependencies.
Now build.
colcon build && source ~/.bashrcIn a real robotics project, the naming convention for this package would be:
<robot_name>_moveit_config
Create the Configuration Files
Let’s create configuration files that will enable us to tailor our robot for MoveIt 2. We’ll do this process manually (recommended), but you are welcome to use the MoveIt Setup Assistant.
You can see some official examples of configuration files for other robots on the MoveIt resources ROS 2 GitHub.
Add the Configuration Files to the Config Folder
MoveIt 2 requires configuration files to go into the config folder of the package.
Open a terminal window, and type:
cd ~/ros2_ws/src/mycobot_ros2/mycobot_moveit_config/config/mycobot_280Add SRDF
The first thing we need to do is set up the SRDF File.
Semantic Robot Description Format (SRDF) is a file that tells MoveIt how your robot prefers to move and interact with its environment. It is a supplement to the URDF file.
The SRDF adds semantic (meaning-based) information to the robot’s description that isn’t included in the URDF (Unified Robot Description Format). This file includes things like:
- Naming groups of joints or links (e.g., “arm”, “gripper”)
- Defining default robot poses (e.g., “home”, “closed”, etc.)
- Which parts of the robot should be checked for colliding with each other during movement.
- We need to do this step because checking every possible collision between all parts of the robot for each planned movement can be time-consuming, especially for complex robots.
touch mycobot_280.srdfAdd this code.
Save the file, and close it.
Let’s go through each section briefly:
- <group name=”arm”>: This section defines a group named “arm” that includes a list of joints. The joints listed in this group represent the robot arm.
- <group name=”gripper”>: This section defines a group named “gripper” that includes a list of joints related to the robot’s gripper or end-effector.
- <group_state name=”home” group=”arm”>: This section defines a named state called “home” for the “arm” group. It specifies the joint values for the arm joints when the robot is in its home position.
- <group_state name=”open” group=”gripper”>: This section defines a named state called “open” for the “gripper” group, specifying the joint value for the gripper when it is in its open position.
- <disable_collisions>: This section is used to disable collision checking between specific pairs of links. Each <disable_collisions> entry specifies two links and the reason for disabling collision checking between them. The reasons can be “Adjacent” (for adjacent links in the robotic arm), “Never” (for links that will never collide), or “Default” (for links that are not expected to collide in most configurations).
Add Initial Positions
Now let’s create a configuration file for the initial positions.
cd ~/ros2_ws/src/mycobot_ros2/mycobot_moveit_config/config/mycobot_280touch initial_positions.yamlAdd this code.
# Default initial position for each movable joint
initial_positions:
link1_to_link2: 0.0
link2_to_link3: 0.0
link3_to_link4: 0.0
link4_to_link5: 0.0
link5_to_link6: 0.0
link6_to_link6_flange: 0.0
gripper_controller: 0.0
Save the file. This code sets the default initial positions for each movable joint.
The initial_positions.yaml file in MoveIt specifies the starting joint positions for motion planning, overriding any default positions set in the URDF. It allows you to set a specific initial configuration for your robot in MoveIt without modifying the URDF, providing flexibility in defining the starting point for motion planning tasks.
Add Joint Limits
touch joint_limits.yamlAdd this code.
default_velocity_scaling_factor: 1.0
default_acceleration_scaling_factor: 1.0
joint_limits:
link1_to_link2:
has_velocity_limits: true
max_velocity: 2.792527
has_acceleration_limits: true
max_acceleration: 5.0
has_deceleration_limits: true
max_deceleration: -5.0
has_jerk_limits: false
max_jerk: 6.0
has_effort_limits: true
max_effort: 56.0
link2_to_link3:
has_velocity_limits: true
max_velocity: 2.792527
has_acceleration_limits: true
max_acceleration: 5.0
has_deceleration_limits: true
max_deceleration: -5.0
has_jerk_limits: false
max_jerk: 6.0
has_effort_limits: true
max_effort: 56.0
link3_to_link4:
has_velocity_limits: true
max_velocity: 2.792527
has_acceleration_limits: true
max_acceleration: 5.0
has_deceleration_limits: true
max_deceleration: -5.0
has_jerk_limits: false
max_jerk: 6.0
has_effort_limits: true
max_effort: 56.0
link4_to_link5:
has_velocity_limits: true
max_velocity: 2.792527
has_acceleration_limits: true
max_acceleration: 5.0
has_deceleration_limits: true
max_deceleration: -5.0
has_jerk_limits: false
max_jerk: 6.0
has_effort_limits: true
max_effort: 56.0
link5_to_link6:
has_velocity_limits: true
max_velocity: 2.792527
has_acceleration_limits: true
max_acceleration: 5.0
has_deceleration_limits: true
max_deceleration: -5.0
has_jerk_limits: false
max_jerk: 6.0
has_effort_limits: true
max_effort: 56.0
link6_to_link6_flange:
has_velocity_limits: true
max_velocity: 2.792527
has_acceleration_limits: true
max_acceleration: 5.0
has_deceleration_limits: true
max_deceleration: -5.0
has_jerk_limits: false
max_jerk: 6.0
has_effort_limits: true
max_effort: 56.0
gripper_controller:
has_velocity_limits: true
max_velocity: 2.792527
has_acceleration_limits: true
max_acceleration: 5.0
has_deceleration_limits: true
max_deceleration: -5.0
has_jerk_limits: false
max_jerk: 300.0
has_effort_limits: true
max_effort: 56.0
Save the file.
This code sets the velocity and acceleration limits for each joint in our robotic arm, which is used by MoveIt 2 to control the robot’s movements.
Even though we have joint limits for velocity already defined in the URDF, this YAML file allows for overriding. Defining joint limits specific to MoveIt 2 is useful if you want to impose stricter or different limits for particular applications without modifying the URDF. It provides flexibility in adjusting the robot’s behavior for different tasks.
Add Kinematics
touch kinematics.yamlAdd this code, and save the file.
# Configures how a robot calculates possible positions and movements of its joints
# to reach a desired point. It specifies which mathematical methods (solvers) to use,
# how long to try, and how precise these calculations should be.
arm: # Name of the joint group from the SRDF file
kinematics_solver: kdl_kinematics_plugin/KDLKinematicsPlugin # Plugin used for solving kinematics
kinematics_solver_search_resolution: 0.005 # Granularity (in radians for revolute joints) used by the solver when searching for a solution.
kinematics_solver_timeout: 0.05 # Maximum time the solver will spend trying to find a solution for each planning attempt
position_only_ik: false # If true, the solver will only consider the position of the end effector, not its orientation
kinematics_solver_attempts: 5 # How many times the solver will try to find a solution
# Typically we don't need a complex kinematics solver for the gripper. This is for demonstration purposes only.
gripper:
kinematics_solver: kdl_kinematics_plugin/KDLKinematicsPlugin
kinematics_solver_search_resolution: 0.005
kinematics_solver_timeout: 0.05
position_only_ik: false
kinematics_solver_attempts: 3
arm_with_gripper:
kinematics_solver: kdl_kinematics_plugin/KDLKinematicsPlugin
kinematics_solver_search_resolution: 0.005
kinematics_solver_timeout: 0.05
position_only_ik: false
kinematics_solver_attempts: 5
This file configures how MoveIt 2 calculates possible positions and movements of the robot’s arm to reach a desired point in space. It specifies the mathematical methods, precision, and time limits for these calculations, which MoveIt 2 uses to plan the robot’s movements.
Add Controllers
touch moveit_controllers.yamlAdd this code, and save the file.
# This file configures the controller management for MoveIt, specifying which controllers are available,
# the joints each controller handles, and the type of interface (e.g. FollowJointTrajectory).
moveit_controller_manager: moveit_simple_controller_manager/MoveItSimpleControllerManager # Specifies the controller manager to use.
# Define the controllers configured using the ROS 2 Control framework.
moveit_simple_controller_manager:
controller_names:
- arm_controller # Name of the controller for the robotic arm.
- gripper_action_controller # Name of the controller for the gripper
# Configuration for the arm_controller.
arm_controller:
action_ns: follow_joint_trajectory # ROS action namespace to which MoveIt sends trajectory commands.
type: FollowJointTrajectory # Type of the controller interface; follows a joint trajectory.
default: true # This controller is the default for the joints listed below.
joints: # List of joints that the arm_controller manages.
- link1_to_link2
- link2_to_link3
- link3_to_link4
- link4_to_link5
- link5_to_link6
- link6_to_link6_flange
# Configuration for the gripper_action_controller.
gripper_action_controller:
action_ns: gripper_cmd
type: GripperCommand
default: true
joints:
- gripper_controller
This yaml file tells MoveIt 2 how to convert its motion plans into instructions that the ROS 2 controllers can understand and execute on the real (or simulated) robot. Without this, MoveIt 2 wouldn’t know how to make the robot actually move using the ROS 2 control system.
MoveIt 2 sends desired joint positions or trajectories to ROS 2 controllers, which then manage the low-level control of the robot’s motors. This integration allows MoveIt 2 to focus on high-level motion planning while relying on ROS 2 control for the actual execution on the robot hardware.
We see that three ROS 2 controllers are available:
- arm_controller: This is a Joint Trajectory Controller for the robot arm
- gripper_action_controller: This is a Gripper Action Controller for the gripper
We also see a list of joints associated with each controller.
The arm controller uses the “FollowJointTrajectory” action interface. The FollowJointTrajectory action interface is a standardized interface in ROS (Robot Operating System) for controlling the joint positions of a robot over time. It allows MoveIt 2 to send a trajectory, which is a sequence of joint positions and their corresponding timestamps, to the robot’s joint controllers.
How it works:
- MoveIt 2 plans a movement, which results in a series of joint positions over time.
- This plan is packaged into a “trajectory” – think of it as a list of goal positions (in radians) for each joint.
- MoveIt 2 sends this trajectory to the appropriate ROS 2 controller using the FollowJointTrajectory action interface. This interface is like a protocol MoveIt 2 uses to communicate with the controllers.
- The ROS 2 controller receives this trajectory, processes it, and relays it to the hardware interface.
- The hardware interface sends the commands to the microcontroller (e.g. Arduino) to move the robot’s joints accordingly.
Add Cartesian Speed and Acceleration Limits
For motion planning for our robotic arm, we need to add the Pilz industrial motion planner.
Pilz focuses on simple, predictable movements like straight lines, circles, and direct point-to-point paths. It works by calculating a clear, predefined route for each part of the robot to follow, ensuring smooth and safe motion from start to finish.
Think of Pilz as a careful driver that always takes known, reliable routes rather than trying to find creative shortcuts, making it perfect for precise tasks where you want consistent, controlled movements.
While default planners like OMPL (Open Motion Planning Library) work best for dynamic environments where you can have unexpected obstacles (people moving around, objects left on tabletops and counters, etc.), the structured and predictable nature of Pilz is advantageous in a scenario where the environment is well-structured and controlled.
Open a new file where we will define the Cartesian limits:
touch pilz_cartesian_limits.yaml
# Defines the Cartesian movement limits for a robotic arm using the Pilz Planner.
# The values are typically determined based on a combination of the robot manufacturer's
# specifications, practical testing, and considerations for the specific tasks the robot will perform.
cartesian_limits:
max_trans_vel: 1.0 # Maximum translational velocity in meters per second. Specifies how fast the end effector can move in space.
max_trans_acc: 2.25 # Maximum translational acceleration in meters per second squared. Determines how quickly the end effector can increase its speed.
max_trans_dec: -5.0 # Maximum translational deceleration in meters per second squared. Specifies how quickly the end effector can decrease its speed.
max_rot_vel: 1.57 # Maximum rotational velocity in radians per second. Controls the speed at which the end effector can rotate.
Save the file, and close it.
This file sets speed and acceleration limits for a robotic arm’s movement in space. It defines how fast and quickly the robot’s end effector can move and rotate in Cartesian space (X, Y, Z direction) to ensure safe and efficient operation within the robot’s workspace.
Why do we need this file if we have already set velocity limits inside the URDF?
The URDF and the MoveIt configuration files serve different purposes when it comes to controlling the robot’s motion. The URDF contains velocity limits for each individual joint, which determine how fast each joint can move. These limits are important for controlling the speed of the individual joints. For example:
<joint name="joint_name" type="revolute">
<limit lower="-2.879793" upper="2.879793" effort="5.0" velocity="2.792527"/>
</joint>
On the other hand, the cartesian_limits in the MoveIt configuration are used to control the speed and motion of the robot’s gripper in 3D space. These limits define how fast the gripper can move and rotate in the world coordinate frame (X, Y, Z axes). The cartesian_limits are essential for planning the overall motion of the robot and ensuring that it moves safely and efficiently when performing tasks.
So, while the URDF velocity limits are important for controlling individual joints, the MoveIt cartesian_limits are still necessary for proper motion planning and control of the gripper’s movement in 3D space.
By the way, in the context of the file name “pilz_cartesian_limits.yaml”, “pilz” refers to Pilz GmbH & Co. KG, a German automation technology company that specializes in safe automation solutions, including robotics.
Add a Planning Pipeline File for the Pilz Industrial Motion Planner
To make all this work, we need to add a file called pilz_industrial_motion_planner_planning_planner.yaml.
Here is an example file from MoveIt’s GitHub.
This file preprocesses the robot’s motion planning request to make sure it meets certain safety and feasibility criteria, like ensuring the robot’s starting position is safe and within allowed limits before planning its movement.
cd ~/ros2_ws/src/mycobot_ros2/mycobot_moveit_config/config/touch pilz_industrial_motion_planner_planning.yamlAdd this code.
planning_plugins:
- pilz_industrial_motion_planner/CommandPlanner
# The order of the elements in the adapter corresponds to the order they are processed by the motion planning pipeline.
request_adapters:
- default_planning_request_adapters/ValidateWorkspaceBounds
- default_planning_request_adapters/CheckStartStateBounds
- default_planning_request_adapters/CheckStartStateCollision
default_planner_config: PTP
capabilities: >-
pilz_industrial_motion_planner/MoveGroupSequenceAction
pilz_industrial_motion_planner/MoveGroupSequenceService
Save the file, and close it.
Add a Planning Pipeline File for the OMPL Planner
Now add a pipeline file for another planner called OMPL (Open Motion Planning Library).
OMPL is a sampling-based motion planning framework integrated into that provides various probabilistic algorithms like RRT, PRM, and their variants to find collision-free paths for robots. OMPL handles the complex task of planning feasible trajectories while avoiding obstacles, though it doesn’t inherently optimize for smoothness or dynamics.
cd ~/ros2_ws/src/mycobot_ros2/mycobot_moveit_config/config/touch ompl_planning.yamlAdd this code.
Save the file, and close it.
Add a Planning Pipeline File for the STOMP Planner
Now add a pipeline file for another planner called STOMP.
STOMP (Stochastic Trajectory Optimization for Motion Planning) is a method of planning robot motion that uses random adjustments to improve paths. Think of it like constantly fine-tuning a rough sketch until you get a perfect drawing, but for robot movements.
cd ~/ros2_ws/src/mycobot_ros2/mycobot_moveit_config/config/touch stomp_planning.yamlAdd this code.
Save the file, and close it.
Add an RViz Configuration File
Let’s create a file that sets the parameters for visualizing all this in RViz.
cd ~/ros2_ws/src/mycobot_ros2/mycobot_moveit_config/mkdir rviz && cd rviztouch move_group.rvizAdd this code.
Save the file, and close it.
Create a Launch File
Let’s create a launch file.
Open a terminal window, and type:
cd ~/ros2_ws/src/mycobot_ros2/mycobot_moveit_config/launch/Create the following file:
touch move_group.launch.pyAdd this code.
Save the file, and close it.
This launch file launches MoveIt and RViz.
Looking at the source code for the moveit_configs_builder helped me to complete this launch file.
Create a Setup Assistant File
The .setup_assistant file is typically created automatically when you use the MoveIt Setup Assistant to configure your robot. We are going to create a basic one since MoveIt expects this file to be inside your package (it will spit out warnings if it is not in the root of the package).
Create a new file named .setup_assistant in the root directory of your MoveIt configuration package (e.g., mycobot_moveit_config).
cd ~/ros2_ws/src/mycobot_ros2/mycobot_moveit_config/touch .setup_assistantAdd this code:
moveit_setup_assistant_config:
URDF:
package: mycobot_description
relative_path: urdf/robots/mycobot_280.urdf.xacro
SRDF:
relative_path: config/mycobot_280/mycobot_280.srdf
CONFIG:
author_name: AutomaticAddison
author_email: addison@todo.com
generated_timestamp: 1734048000Save the file, and close it.
Remember to update this file, if you use a robot other than the myCobot 280.
Set file permissions.
sudo chmod 644 .setup_assistantAdd an RGBD Camera
Let’s add an RGBD camera to our robot so that we can eventually run a pick and place task.
Let’s start by creating a URDF file for an RGBD camera. An RGBD camera captures both color (Red Green Blue) images and depth information, allowing it to see the world in 3D like human eyes do.
Gazebo has many sensors available, including one specifically for an RGBD camera.
We will add to the URDF we currently have.
cd ~/ros2_ws/src/mycobot_ros2/mycobot_description/meshes/mkdir -p d435/visual/Add this d435.stl file.
cd ~/ros2_ws/src/mycobot_ros2/mycobot_description/urdf/sensors/touch intel_rgbd_cam_d435.urdf.xacroAdd this code in that file.
Save the file, and close it.
Edit the main robot state publisher file with the use_camera parameter.
cd ~/ros2_ws/src/mycobot_ros2/mycobot_description/launch/Here is what the robot_state_publisher.launch.py should look like.
Now add the ROS 2 bridge parameter file.
cd ~/ros2_ws/src/mycobot_ros2/mycobot_gazebo/mkdir configAdd this file to the config folder:
touch ros_gz_bridge.yamlUpdate CMakeLists.txt to add the config folder to the install path.
# Copy necessary files to designated locations in the project
install (
DIRECTORY config launch models worlds
DESTINATION share/${PROJECT_NAME}
)
Save the file, and close it.
Now edit the main launch file to bridge the 3D point cloud topic over from Gazebo to ROS 2.
cd ~/ros2_ws/src/mycobot_ros2/mycobot_gazebo/launchOpen the mycobot.gazebo.launch.py file, and make it look like this.
Now edit your launch script:
cd ~/ros2_ws/src/mycobot_ros2/mycobot_bringup/scriptsOpen the mycobot_280_gazebo.sh and the mycobot_280_gazebo_and_moveit.sh file, and add the use_camera parameter to the launch call. Make it true.
We also need to add a little delay on the loading of the joint state broadcaster.
cd ~/ros2_ws/src/mycobot_ros2/mycobot_moveit_config/launchOpen load_ros2_controllers.launch.py.
Make it look like this file.
Save the file, and close it.
Edit package.xml
Let’s edit the package.xml file with the dependencies.
cd ~/ros2_ws/src/mycobot_ros2/mycobot_moveit_config/Open the package.xml file.
Add this code.
Save the file, and close it.
Edit CMakeLists.txt
Update CMakeLists.txt with the new folders we have created.
cd ~/ros2_ws/src/mycobot_ros2/mycobot_moveit_config/Open CMakeLists.txt.
Add this code.
cmake_minimum_required(VERSION 3.8)
project(mycobot_moveit_config)
if(CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER_ID MATCHES "Clang")
add_compile_options(-Wall -Wextra -Wpedantic)
endif()
# find dependencies
find_package(ament_cmake REQUIRED)
find_package(moveit_ros_planning_interface REQUIRED)
find_package(moveit_ros_move_group REQUIRED)
find_package(moveit_kinematics REQUIRED)
find_package(moveit_planners_ompl REQUIRED)
find_package(moveit_ros_visualization REQUIRED)
find_package(rviz2 REQUIRED)
find_package(rviz_visual_tools REQUIRED)
# Copy necessary files to designated locations in the project
install (
DIRECTORY config launch rviz
DESTINATION share/${PROJECT_NAME}
)
# Install the .setup_assistant file
install(
FILES .setup_assistant
DESTINATION share/${PROJECT_NAME}
)
if(BUILD_TESTING)
find_package(ament_lint_auto REQUIRED)
# the following line skips the linter which checks for copyrights
# comment the line when a copyright and license is added to all source files
set(ament_cmake_copyright_FOUND TRUE)
# the following line skips cpplint (only works in a git repo)
# comment the line when this package is in a git repo and when
# a copyright and license is added to all source files
set(ament_cmake_cpplint_FOUND TRUE)
ament_lint_auto_find_test_dependencies()
endif()
ament_package()Save the file, and close it.
Create a Launch Script
Let’s bring it all together by creating a launch script.
cd ~/ros2_ws/src/mycobot_ros2/mycobot_bringup/scriptstouch mycobot_280_gazebo_and_moveit.shAdd this code.
Save the file, and close it.
I set my desired Gazebo camera pose in the script. When you launch everything, you can see your current camera pose by typing this command:
gz topic -t /gui/camera/pose -eBuild the Package
Now let’s build the package.
cd ~/ros2_ws/colcon buildsource ~/.bashrcLaunch the Demo and Configure the Plugin
Begin by launching the robot in Gazebo along with all the controllers (i.e. arm_controller, gripper_action_controller.
cd ~/ros2_ws/src/mycobot_ros2/mycobot_bringup/scriptssudo chmod +x mycobot_280_gazebo_and_moveit.shbash ~/ros2_ws/src/mycobot_ros2/mycobot_bringup/scripts/mycobot_280_gazebo_and_moveit.shThis will:
- Start Gazebo
- Spawn the robot
- Start the robot_state_publisher
- Load and start the necessary controllers (joint_state_broadcaster, arm_controller, gripper_action_controller)
The script will then:
- Start the move_group node
- Launch RViz with the MoveIt configuration
- Use the simulation time from Gazebo
Here is what your screen should look like when everything is loaded properly. You will notice that on the right-hand side of Gazebo I closed the two panels. You can close them by right-clicking and hitting “Close”.
Let’s check out the active topics:
ros2 topic list
The active nodes are:
ros2 node list
Here are our available action servers:
ros2 action list
Here are our services. You will see we have a lot of services. This page at the ROS 2 tutorials shows you how we can call services from the command line.
ros2 service listLet’s check out the parameters for the different nodes my launching a GUI tool called rqt_reconfigure:
rqt --standalone rqt_reconfigure
Click “Refresh”.
Click on any of the nodes to see the parameters for that node. For example, let’s take a look at the moveit_simple_controller_manager node.
This tool enables you to see if the parameters you set in the config file of your MoveIt package were set correctly.
You can close the window.
Explore MoveIt in RViz
We will now roughly follow this official MoveIt Quickstart in RViz tutorial which walks you through the main features provided by the MoveIt RViz plugins.
First, click on the Displays panel in the upper left.
Under Global Options, make sure the Fixed Frame is set to “base_link”
Scroll down to the MotionPlanning plugin.
Make sure the Robot Description field is set to robot_description.
Make sure the Planning Scene Topic field is set to /monitored_planning_scene.
Make sure the Trajectory Topic under Planned Path is set to /display_planned_path.
In the Planning Request section, make sure the Planning Group is set to arm. You can also see this in the MotionPlanning panel in the bottom left.
Play With the Robotic Arm
Rviz has four different visualizations for MoveIt. These visualizations are overlapping.
- The robot’s configuration in the /monitored_planning_scene planning environment:
- Planning Scene -> Scene Robot -> Show Robot Visual checkbox
- The planned path for the robot:
- Motion Planning -> Planned Path -> Show Robot Visual checkbox
- Green: The start state for motion planning:
- MotionPlanning -> Planning Request -> Query Start State checkbox
- Orange: The goal state for motion planning:
- MotionPlanning -> Planning Request -> Query Goal State checkbox
You can toggle each of these visualizations on and off using the checkboxes in the Displays panel.
Interact With the Robotic Arm
Now let’s configure our RViz so that all we have are the scene robot, the starting state, and the goal state.
- Check the Motion Planning -> Planned Path -> Show Robot Visual checkbox
- Uncheck the Planning Scene -> Scene Robot -> Show Robot Visual checkbox
- Uncheck the MotionPlanning -> Planning Request -> Query Start State checkbox
- Check the MotionPlanning -> Planning Request -> Query Goal State checkbox
The orange colored robot represents the desired Goal State.
Find the “Joints” tab in the bottom MotionPlanning panel. This lets you control individual joints of the robot.
Try moving the sliders for the joints, and watch how the robot arm changes its pose.
Uncheck the MotionPlanning -> Planning Request -> Query Goal State checkbox.
Check the MotionPlanning -> Planning Request -> Query Start State checkbox.
The green colored robot is used to set the Start State for motion planning.
Use Motion Planning
Now it’s time to plan a movement for your robotic arm using RViz and MoveIt 2.
In the Displays panel in RViz, do the following…
Uncheck the MotionPlanning -> Planning Request -> Query Goal State checkbox
Check the MotionPlanning -> Planning Request -> Query Start State checkbox.
You can see if any links are in collision by going to the MotionPlanning window at the bottom and moving to the “Status” tab.
Move the green (Start State) to where you want the movement to begin.
Rather than using the interactive marker, I find it easier to go to the “Joints” tab in the Motion Planning window at the bottom. This lets you control individual joints of the robot to get your desired Start State.
Uncheck the MotionPlanning -> Planning Request -> Query Start State checkbox.
Check the MotionPlanning -> Planning Request -> Query Goal State checkbox.
Move the orange (Goal State) to where you want the movement to end.
Check the MotionPlanning -> Planning Request -> Query Start State checkbox.
Now let’s plan a motion. Look for the “MotionPlanning” window at the bottom-left part of the screen.
Click the Context tab.
Select ompl.
Now click the Planning tab.
Click the Plan button to generate a motion plan between the start and goal state.
The system will calculate a path, and you should see a preview of the planned motion in the 3D visualization window.
Review the planned path carefully to ensure it’s appropriate and collision-free.
If you’re not satisfied with the plan, you can adjust the start and goal states in the 3D view and plan again.
Once you’re happy with the plan, click the Plan & Execute button to make the robot carry out the planned motion.
You should see your simulated robotic arm moving in both Gazebo and RViz.
If you want to speed things up, you can tweak the Velocity Scaling figures on the Planning tab. You can make them all 1.0 for example.
Then click Plan & Execute again.
Keep setting new Goal States and moving your arm to different poses.
Be careful not to move your robot into a Goal State where the robot appears red. Red links on your robot mean the robot is colliding with itself.
If you want to open and close the gripper. The steps are the same.
Go to the MotionPlanning window at the bottom-left.
Go to the Planning tab.
Change the Planning Group to gripper.
Select closed as the Goal State. Remember this is one of the states we configured in the SRDF file.
Click Plan & Execute. No need to click Plan first and then Execute since this is a simple motion.
You should see the gripper close in Gazebo.
You can also make motion plans for the combined arm and gripper group. Have fun with it, and play around to get a feel for MoveIt2 in Rviz.
You can try other planners other than OMPL if you like.
I have set up Pilz and STOMP as some alternative motion planning libraries. Just use the dropdown menu on the Context tab.
Introspecting Trajectory Waypoints
Understanding how your robot moves in detail is important for ensuring smooth and safe operations. Let’s explore a tool that allows us to do just that:
Add a new tool to RViz.
- Click on the “Panels” menu
- Choose “Trajectory – Trajectory Slider”
- You’ll see a new slider appear in RViz
Plan a movement:
- Set a new goal pose for the robotic arm.
- Click the “Plan” button
Use the new Trajectory Slider:
- Move the slider to see each step of the robot’s planned movement
- Press the “Play” button to watch the whole movement smoothly
Remember: If you change where you want the robot to go, always click “Plan” again before using the slider or “Play” button. This makes sure you’re looking at the newest plan, not an old one.
This tool helps you understand exactly how your robot will move from start to finish.
Plan Cartesian Motions
Sometimes, you want your robot to move in a straight line. Here’s how to do that.
Go to the MotionPlanning panel at the bottom-right of the screen.
Click the Planning tab.
Click the Use Cartesian Path checkbox.
What does this do?
- When checked, the robot will try to move its end-effector in a straight line.
- This is useful for tasks that need precise, direct movements, like drawing a straight line or moving directly towards an object.
Why is this important?
- Normal planning might move the robot’s arm in a curved or complex path.
- Cartesian planning ensures a more predictable, straight-line movement.
Try planning some movements with this option on and off to see the difference in how the robot moves. You will need to try different joint goal locations to get a plan that works (many will fail).
That’s it! Keep building!