Migrate from MoveIt 2 to MoveIt Pro Core

This guide is for developers already using open-source MoveIt 2 who want to adopt MoveIt Pro Core. It explains how the two relate, what carries over from your existing setup unchanged, and what changes at the package, namespace, and planner level.

It is a high-level orientation, not a line-by-line port. For the exact include-path and namespace rename tables, it links to the 9.0 User Workspace Migration guide rather than duplicating them.

What MoveIt Pro Core is

MoveIt Pro ships as three products: the Developer Platform (build, simulate, and debug applications through the web UI), the Runtime (the real-time libraries embedded on a deployed robot), and Core. See Technical Specifications for the full comparison.

MoveIt Pro Core is the standalone distribution of the MoveIt Pro real-time controllers, inverse kinematics solvers, and motion planners. It is deliberately lean — packaged with very few dependencies, and very few ROS dependencies in particular: its core libraries depend on ROS messages but not the wider ROS stack, so they can be used largely independently. It is the layer closest to open-source MoveIt 2: a set of C++ libraries, with Python bindings, that you call from your own code rather than an application framework or a web UI. If today you depend on the MoveIt 2 C++ or Python libraries directly, Core is the equivalent commercial layer.

This guide covers Core only

Migrating to Core is a library-to-library change. Adopting the Developer Platform instead is a larger shift — from writing motion-planning C++ to authoring Objectives (Behavior Trees built from Behaviors) inside robot configuration packages — and is not covered here.

What carries over unchanged

MoveIt Pro Core consumes the same robot description and ROS 2 control inputs you already have. None of the following needs to be rewritten:

• URDF and SRDF — your robot model and semantic description load as-is. The Core Python bindings, for example, load a robot model directly from URDF and SRDF files.
• Planning group and kinematics definitions — joint groups, tip links, and joint limits defined in your SRDF and config files are reused.
• ros2_control configuration — Core runs on the standard ros2_control stack. It provides additional real-time controllers (admittance, velocity-force, joint velocity) that build on the interfaces you already expose; see Motion Control Features in Technical Specifications.
• Standard ROS 2 message interfaces — control_msgs/FollowJointTrajectory, sensor_msgs/JointState, and the other interfaces listed in Technical Specifications are unchanged.

In short: your robot stays described the way MoveIt 2 already describes it. What changes is the libraries you link against and the planners you call.

What changes

Package and namespace renames

The core upstream MoveIt libraries are shipped under MoveIt Pro names:

Upstream (MoveIt 2)	MoveIt Pro Core
moveit_core	moveit_pro_base
moveit_ros_planning (planning scene monitor, occupancy map monitor, etc.)	moveit_pro include/namespace root — see the 9.0 guide for the exact per-package dependency mapping
moveit_task_constructor (MTC)	MoveIt Pro Task Constructor (included in Core)

C++ namespaces move alongside the packages — former moveit_core types nest under moveit_pro::base (e.g. moveit::core::RobotState becomes moveit_pro::base::RobotState), while former moveit_ros_planning types nest under moveit_pro (e.g. planning_scene_monitor::PlanningSceneMonitor becomes moveit_pro::planning_scene_monitor::PlanningSceneMonitor).

If your code includes MoveIt headers or uses MoveIt core types directly, update the include paths, namespaces, and your CMakeLists.txt / package.xml dependencies. The 9.0 User Workspace Migration guide has the complete mapping tables (and sed commands) under MoveIt Core Include Path Changes, MoveIt Core C++ Namespace Changes, and MoveIt Core Package Dependency Changes.

Planners: OMPL is replaced

This is the most significant conceptual change. OMPL is no longer used anywhere in MoveIt Pro — it was deprecated over earlier releases, and select algorithms were re-implemented from first principles (see the release notes and the MoveIt Pro Core page). If your MoveIt 2 application configures an OMPL planner pipeline, you migrate to the Core planners instead:

• Deterministic global joint-space planning (ProRRT) — replaces sampling-based OMPL planners for collision-free joint-space motion. Despite the RRT name, ProRRT is deterministic: the same inputs always produce the same solution. This is the same planner exposed to Python as pro_rrt (see Calling Core from Python).
• Cartesian planning — under-constrained Cartesian paths that blend at corners and behave well near singularities.
• Trajectory blending — stitch a sequence of trajectories into one smooth motion without full stops between segments.
• Inverse kinematics — pose IK and path IK solvers.

Migrating planners is not a rename — it is choosing the Core planner that matches the motion you were producing with OMPL, then configuring it. Review the Motion Control Features in Technical Specifications to map your current planning calls onto the Core equivalents.

Visual servoing: MoveIt Servo is replaced

If you used MoveIt Servo for real-time Cartesian or joint jogging, that role is filled by MoveIt Pro's real-time-safe controllers rather than a separate servo node:

• Cartesian streaming — the Velocity-Force Controller (VFC), a real-time Cartesian velocity/force controller that stays robust at singularities. For frame-tracking ("visual servoing"), Velocity IK computes the joint velocities that follow a moving target frame, which the VFC then executes.
• Joint streaming — the Joint Velocity Controller, driven through the standard control_msgs/JointJog interface. The Joint Jog teleoperation mode adds continuous collision checking on top.

Servo is no longer packaged with MoveIt Pro. It can still be built and launched separately if you need it, but the controllers above are the supported path.

Cartesian motion: the Pilz planner is replaced

As with OMPL, the Pilz Industrial Motion Planner is not part of MoveIt Pro. Its deterministic Cartesian motions map onto MoveIt Pro's Cartesian planning and Cartesian controller:

• Linear (LIN) and multi-waypoint Cartesian paths — the Cartesian planner's Path IK (PlanCartesianPath) produces under-constrained paths built from straight-line segments with blended corners, and can relax orientation constraints per axis. See Cartesian Path Following.
• Point-to-point (PTP) motion — the deterministic global joint-space planner (ProRRT) covered above.
• Blended sequences — trajectory blending stitches a sequence into one smooth motion without stopping at intermediate waypoints.
• Real-time Cartesian execution — the Velocity-Force Controller executes Cartesian motion in real time and remains well-behaved near singularities.

Migration process

1. Install MoveIt Pro Core. Download the archive for your ROS 2 distribution and CPU architecture and install its Debian packages. Core requires Ubuntu and ROS 2 versions that match the archive (Humble → 22.04, Jazzy → 24.04). See Install MoveIt Pro Core.
2. Set your license key. Export MOVEIT_LICENSE_KEY (e.g. export MOVEIT_LICENSE_KEY=<your-key>) in the environment that runs your nodes.
3. Point Core at your existing robot model. Reuse your URDF, SRDF, and planning group definitions as-is.
4. Update includes, namespaces, and dependencies. Apply the rename tables from the 9.0 guide to any code that links MoveIt core libraries directly.
5. Replace OMPL planning calls with the corresponding Core planner (deterministic global, Cartesian, or trajectory blending) and configure it.
6. Build and validate against your robot, in simulation or on hardware.

Calling Core from Python

MoveIt Pro Core includes Python bindings (moveit_pro_py, shipped in the Core archive from step 1) over its C++ algorithms: single-pose and path IK, Cartesian planning, the ProRRT planner, Jacobian computation, planning-scene and robot-state management, and trajectory generation from waypoints. The same license key applies. This is often the fastest way to exercise Core against your existing URDF/SRDF before integrating it into your C++ nodes. See the API Reference (Doxygen) for the full binding signatures.

A continuously improving platform

MoveIt Pro is under active development, and new features ship in every release. If Core is missing a planner, controller, solver, or integration your application needs, PickNik can add it — and we are highly responsive to feature requests, especially during the solutioning and requirements-gathering phases of contracting, where we work directly with your team to scope what your deployment requires. Contact us to start that conversation.