Overview of Robot Config & Objective Packages

tip

Some robots are already compatible with MoveIt Pro, see our full list of robots on our ROS 2 Hardware Ecosystem page.

Robot Inheritance and Objective Packages

Scaling robot configurations both in development and deployment typically involves the following challenges:

• Robot software must provide a description of the hardware it commands.
• Robot software must provide a configuration file for the algorithms it uses to optimize performance.
• During development, the hardware being evaluated and algorithm tuning changes often.
• Over the lifetime of deployment, variations in hardware and new algorithm options may be introduced over time to new robots in the fleet.

MoveIt Pro provides two powerful mechanisms to address these challenges: robot configuration package inheritance and objective packages. By using these mechanisms you will avoid having many copies of the same or nearly the same configuration files and Objectives polluting your repository and reduce risk of incorrect provisioning of new robots.

MoveIt Pro Robot Configuration Package Inheritance

MoveIt Pro enables inheritance of a robot's config.yaml file and overriding specific fields. This is useful for development robots or fleet deployment where you may want to describe small variations on the configuration, such as:

• Variations in hardware connectivity, such as the serial number of a sensor.
• Arguments to pass to a xacro file, such as the type of hardware to connect to (spinning up a simulator instance versus launching ros2_control drivers).
• Changing the expected path to a kinematic or camera calibration file .

The next series of guides will explain how to use the config.yaml based_on_package key to inherit config.yaml content from a "parent" robot configuration.

MoveIt Pro Objective Packages

Using the robot configuration inheritance system, you can add entries in an inherited robot config's objectives.objective_library_paths mapping to provide new capabilities or overload the parent configuration's definition of an Objective. This is useful when you need to overload a specific Subtree due to a small variation in hardware. For example, the Open Gripper implementation of a variation on your robot that has a slightly wider grip.

MoveIt Pro also enables creating ROS packages with Behavior and Objective definitions, which can then be included in a robot configuration package. This enables easy reuse of Objectives and Behaviors even across robot configurations that do not share an inheritance chain. Reasons you would want to do something like this include:

• If your development or production fleet uses variations on hardware that achieve similar robot form factor. For example if you have a 2nd type of robot with a different brand arm (with similar reachability) or vacuum gripper.
• If you have hierarchical variations in form factors, such as a static robot arm and a mobile manipulator version of that arm. Here you would have a package of manipulation capabilities either platform could leverage and a 2nd package of navigation specific Objectives only the mobile manipulator robot configuration would include.

Note that this sharing of Objectives across small and large variations in form factor is only possible due to the dynamic planning and software defined architecture of MoveIt Pro. Older approaches of motion planning, such as waypoint based planning, would prevent this level of inheritance and reuse.

The next series of guides will explain how to use the objectives entry in your config.yaml dictionary to share objectives across your robot configurations.

Robot Naming Conventions

Combining the two above mechanisms, below are some recommendations on naming and structuring your robot configurations:

1. Choose a descriptive prefix for your robot configuration package's name. This may be the name of your robot model you are selling (the Asimov 5000) or may just be a descriptive name of the development platform (Two arm UR).

2. "Generational" changes to robots should live in a new repository When a hardware revision to your robot is significant enough most of your configuration files change, we recommend making a new repository. Keeping several "generations" of robots in the same repository often leads to slower development in your IDE of choice due to having several definitions of the various configuration files, since inheritance is not of use. "Generational" changes is subjective but typically involves something like changing the arm vendor or kinematics of the robot arm(s). This entails significant changes to your URDF and most configuration files, meaning inheritance would be of little use.

3. Use the suffix to indicate inherited variations on a config. We primarily use inheritance to change what type of system MoveIt Pro will talk to, such as _mock, (for ros2_control mock hardware), _sim (for MoveIt Pro Sim), and _hw (for physical hardware).

   • asimov_5000_mock
   • dual_ur_hw

4. If you require per-physical-robot customization of a robot config, add the asset ID to the robot configuration name. If your robot provisioning is largely consistent, for example the ports used to talk to hardware are always the same, calibration files are always in the same place, etc, then this may not be necessary. Some sensors, such as Realsense cameras, require providing the serial number of the camera, and thus require per-robot customization.

   • asimov_5000_001_hw
   • asimov_5000_099_hw

5. If you are rapidly iterating on small revisions to robot hardware, but need to continue supporting both versions, use inheritance and additional information to the robot config name.

   • asimov_5000_proto1_sim
   • asimov_5000_proto2_sim

   "Revisional" changes is also subjective but might be something like swapping out the type of 2 finger or vacuum suction gripper. There will be small changes to your URDF, but the config.yaml files will largely remain the same (and make use of inheritance). We recommend doing this so you will not have to jump through your Git history when you need to test something on the original prototype. This is particularly common when wanting to develop in sim against the new prototype, but only having access to the older prototype on hardware.

Robot Config and Objective Package Inheritance Examples

asimov_5000_config

lovelace_config