MoveIt! provides a user-friendly graphical interface for the purpose of integrating a new robotics arm into it. The Setup Assistant takes care of generating all of the configuration files and launch scripts based on the information provided by the user. In general, it is the easiest way to start using MoveIt! as it also generates several demonstration launch scripts, which can be used to run the system without a physical arm or simulation in place.

In order to launch the Setup Assistant, the following command needs to be executed in a terminal:

    $ roslaunch moveit_setup_assistant setup_assistant.launch 

Once the command has been executed, a window similar to the one shown above should appear; in this particular case, the goal is to generate a new configuration, so that's the button we should aim for. Once the button has been pressed, the assistant will request a URDF or COLLADA model of the robotic arm, which for our example arm can be found at rosbook_arm_description/robots/rosbook_arm_base.urdf.xacro inside the repository package.

Please note that the robot description provided is in theXML Macros (Xacro) format, which makes it easier to generate complex URDF files. Once the robot description has been loaded, the reader needs to go through each tab and add the required information. The first tab, as seen in following figure, is used to generate the self-collision matrix.

Fortunately for the user, this process is performed automatically by simply setting the sampling density (or using the default value), and clicking on the Regenerate Default Collision Matrix button. The collision matrix contains information about how and when links collide in order to improve the performance of the motion planner. The figure below shows this in detail:

The second tab, as seen in the following figure, is used to assign virtual joints to the robot. A virtual joint is used to attach the robotic arm to the world as the pose of a robot can vary with respect to it, but in this particular case we won't need a virtual joint because the base of the arm does not move. We need virtual joints when the manipulator is not fixed in one place. For example, if the arm is on top of a mobile platform, we need a virtual joint for the odometry since base_link (base frame) moves with respect to the odom frame.

In the third tab, which can be seen in the following figure, we need to define the planning groups of the robotic arm. Planning groups, as the name suggests, are sets of joints that need to be planned as a group in order to achieve a given goal on a specific link or end effector. In this particular case, we need to define two planning groups: one for the arm itself and another for the gripper. The planning will then be performed separately for the arm positioning and the gripper action.

The fourth tab, as shown in the next screenshot, gives us the ability to define known robot poses in order to be able to reference them later; these predefined poses are also referred to as group states. As we can see, we have set up two different poses: the home position, which corresponds to the stored position of the arm, and the grasping position, which, as the name suggests, should allow the robot to grasp elements in the scene. Setting known poses can have multiple benefits in a real-life situation; for example, it is common to have an initial position from which planning happens, a position where the arm is safe to be stored in a container, or even a set of known positions with which to compare the position accuracy over time.

The fifth tab is used to define the robotic arm's, can be seen in the following figure. As we discussed earlier, the robotic arm usually has an end effector, which is used to perform an action, such as a gripper or some other tool. In our case, the end effector is a gripper, which allows us to pick objects from the scene. In this tab, we need to define the gripper's end effector by assigning it a name, a planning group, and the parent link containing the end effector.

The sixth tab, shown in the following screenshot, is an optional configuration step, which allows us to define joints that cannot be actuated. An important feature of these joints is that MoveIt! doesn't need to plan for them and our modules don't need to publish information about them. An example of a passive joint in a robot could be a caster, but in this case, we'll skip this step as all of our passive joints have been defined as fixed joints, which will eventually produce the same effect on motion planning.

Finally, as seen in the following diagram, the last step in the Setup Assistant is generating the configuration files. The only thing required in this step is to provide the path of the configuration package, which will be created by MoveIt!, and which will contain most of the launch and configuration files required to properly start controlling our robotic arm from MoveIt!

It is important to take into account that the configuration generated by the Setup Assistant has already been provided in the repository and that even though it is recommended that you go through the process, the result can be discarded in favor of the provided package, which is already being referenced by the rest of the launch scripts and configuration files in the repository.