MoveIt 2 vs MoveIt Pro 2026: What Qualcomm’s PickNik Deal Means

Last Updated: September 24, 2026

On September 23, 2026, during ROSCon Toronto week, Qualcomm announced an agreement to acquire PickNik Inc., the Boulder company that maintains MoveIt, the most widely used motion-planning framework in the ROS ecosystem. The price was not disclosed and the deal has not closed. Yet every ROS 2 manipulation team now has to answer a question it could previously postpone: MoveIt 2 vs MoveIt Pro — which one is your product actually built on, and does the owner of the chip roadmap now shape your planning stack? Five days earlier, MoveIt 2.15.2 landed in ROS 2 Lyrical Luth. On the commercial side, MoveIt Pro 9.0 was announced in April with perception-to-motion, whole-body control and redesigned teleoperation, and MoveIt Pro 10.0 followed on September 1 with learned-policy execution and a desktop app. This guide separates the durable engineering comparison from the news. You will leave knowing what each product really contains, where the boundary between them sits, which failure modes bite each, and what the acquisition does and does not change.

What this covers: the MoveIt 2.15 planning pipeline, the MoveIt Pro 9.0 application layer, a decision matrix by team and workload, the Qualcomm Dragonwing and Arduino VENTUNO Q hardware path, trade-offs, a checklist, and an FAQ.

Context and Background

MoveIt started in the ROS 1 era as the motion-planning stack for arms. It grew into the framework most research labs and many integrators reach for first when a robot needs to move without hitting things. MoveIt 2 is the ROS 2 port and successor. It is released under the BSD-3-Clause license, as the moveit/moveit2 repository states. It is packaged per ROS distribution, so what you get depends on which ROS 2 release you run.

For Lyrical Luth, that is the MoveIt 2.15 line. On September 18, 2026, rosdistro pull request #53995 bumped Lyrical from 2.15.1-1 to 2.15.2-1. The maintainer described the release as addressing “some controller spawning issues” ahead of the Lyrical sync. The reviewer merged it after judging that it did not break API or ABI, and noted that an API-breaking change would not have been merged right before ROSCon. If you are still moving a workspace across distributions, our ROS 2 Kilted to Lyrical Luth migration guide covers the build-system and ament changes that surface in MoveIt workspaces too.

MoveIt Pro is a different kind of product. It began as MoveIt Studio, was rebranded MoveIt Pro in 2024, and is sold commercially by PickNik. PickNik CEO Dave Grant has said NASA was the initial funder of MoveIt Pro, which is why teleoperation has been in the product from the start. Pro uses the same planning heritage but wraps it in an application platform: a behavior-tree runtime, an operator UI, perception pipelines, teleoperation and data collection. MoveIt Pro 9.0 was announced publicly on April 2, 2026; PickNik’s own release notes date the 9.0.0 build to February 12, 2026. The line has since moved on: MoveIt Pro 10.0 shipped on September 1, 2026, and 10.1 on September 18.

The acquirer has been building toward robotics for a year. Qualcomm acquired Arduino in October 2025, introduced a general-purpose robotics architecture in January 2026, and joined MassRobotics in April 2026. Its stated aim for PickNik is to streamline MoveIt on Qualcomm Dragonwing platforms, giving developers an “easier path from AI models to planning, manipulation, and real-time control,” according to The Robot Report’s coverage of the deal. Around the same time, Arduino, now a Qualcomm subsidiary, opened pre-orders for the VENTUNO Q board, which is slated to be the first MoveIt integration target.

The comparison below is useful whether or not the deal closes. The news simply raises the stakes on getting it right.

MoveIt 2 vs MoveIt Pro: Library Versus Platform

MoveIt 2 is an open-source motion-planning library and set of ROS 2 nodes: planners, collision checking, kinematics, real-time servoing and trajectory execution. MoveIt Pro is a commercial application platform built on that heritage. It adds a behavior-tree runtime, perception-to-motion pipelines, teleoperation, training-data capture, whole-body control and a UI. You integrate MoveIt 2; you build applications inside MoveIt Pro.

Figure 1: The open-source MoveIt 2.15 core versus the commercial MoveIt Pro layer above it, with 9.x and 10.x features combined.

The lower box is what ships in ROS 2 Lyrical: the move_group node, planner plugins, MoveIt Servo and hybrid planning. Those components talk to ros2_control controllers directly. The upper box is what PickNik sells: a UI driving an Objective Server that sequences perception, teleoperation and whole-body motion. It still calls into planning. Your own code can target either layer, but the ownership of task logic differs sharply.

What MoveIt 2 actually gives you

The Lyrical package list tells you the scope. moveit_core holds the robot model, robot state, planning scene and collision interfaces. moveit_ros_move_group provides the central node that exposes planning and execution as ROS actions and services. Planning is pluggable: moveit_planners_ompl wraps the Open Motion Planning Library’s sampling-based planners, moveit_planners_chomp and moveit_planners_stomp provide optimization-based planners, and pilz_industrial_motion_planner generates deterministic point-to-point, linear and circular industrial moves.

Around that core sit the pieces most teams underuse. moveit_servo does real-time Cartesian or joint jogging with collision and singularity checks. moveit_hybrid_planning pairs a slow global planner with a fast local planner that reacts during execution. moveit_ros_trajectory_cache stores and reuses previously computed plans. moveit_py gives Python bindings. moveit_setup_assistant generates configuration packages, and moveit_simple_controller_manager bridges trajectories to controller action interfaces.

What MoveIt 2 does not give you is equally important. There is no task sequencer beyond what you write yourself. Grasp logic, retries, perception fusion, operator interfaces and fleet deployment are your job. The separate, open-source MoveIt Task Constructor helps with multi-stage manipulation, but it is a planning-time composition tool, not a runtime supervisor.

What MoveIt Pro adds on top

MoveIt Pro organizes every application as an “Objective.” PickNik’s documentation defines an Objective as an application built as a behavior tree, stored in the BehaviorTree.CPP XML format. Each node is a “Behavior,” which the docs describe as the smallest building block: a discrete sensing, planning or motion step. Behaviors run as plugins inside the MoveIt Pro Objective Server, and an Objective is started through a /do_objective action goal.

That design choice matters more than any single feature. In MoveIt 2, task state lives wherever you put it, often inside a Python script. In Pro, task state lives in a reactive tree with a blackboard, subtrees and a visual editor and debugger. PickNik’s example Objectives chain Task Constructor behaviors — initialize, set up, plan, execute — inside tree sequences.

MoveIt Pro 9.0 layered new capability onto that runtime, per The Robot Report’s release coverage:

• Automated contour extraction and rasterized Cartesian path generation from point clouds.
• AI-driven 2D mask filtering and bounding-box analysis.
• ICP-based point-cloud alignment for merging surface scans.
• Whole-body motion control with built-in collision checking and joint-limit enforcement.
• Native mobile-manipulation support covering arms and wheeled bases.
• Redesigned teleoperation and training-data collection with collision checking, multi-arm and coordinated mobile manipulation.
• A refreshed UI with up to six resizable panes, up from four.

Named 9.0 customers include Autowash, which PickNik’s CEO said cut its energy and water use by around 40%, plus Hivebotics and CleanBotix. The pattern is surface work — washing, cleaning, finishing — where perception-derived paths are the whole product.

MoveIt Pro 10: the line you would buy today

If you evaluate Pro now, you are evaluating the 10.x line, not 9.0. According to PickNik’s release notes, MoveIt Pro 10.0 (September 1, 2026) made four changes that matter for this comparison:

• ROS 2 distribution. 10.0 requires ROS 2 Jazzy. Humble support stops at 9.4 and earlier, and Lyrical support is on the roadmap for the 10.x line later in 2026. Open-source MoveIt 2.15 already ships in Lyrical, so for now the two products sit on different ROS 2 distributions.
• Learned policies. 10.0 can execute a vision-language-action model, diffusion policy or other learned policy as continuous, collision-checked motion. It can also record demonstrations from an Objective and export them in LeRobot format for training.
• Desktop app. Runtime deployments no longer serve the web app; operators connect through a signed Linux desktop application, with macOS and Windows listed as coming.
• NVIDIA Jetson. 10.0 runs on Jetson devices under Jazzy with JetPack 7.2, a detail worth weighing against the Qualcomm news.

10.0 also added an MCP server so coding agents can inspect and author Objectives. 10.1 (September 18) added per-joint planning costs and collision padding for world objects and carried payloads. The 9.0 perception-to-motion features described above remain the core of Pro’s surface-processing story.

Why the boundary is the real decision

Here is the thesis of this post. Teams rarely choose between MoveIt 2 and MoveIt Pro on planning quality. Both rest on the same planning ideas. They choose, often without noticing, who owns the task layer. With MoveIt 2 you own it: your behavior trees, state machines and perception glue are your intellectual property and your maintenance burden. With Pro you rent a mature task layer and accept its abstractions.

The Qualcomm deal does not change the planning core’s license, per the companies’ stated intent. It does make the task layer — the commercial part — the piece most likely to be tuned to one silicon vendor. That is why the boundary deserves an explicit architectural decision rather than a default.

Deeper Analysis: Inside the Planning Pipeline and the Objective Runtime

To choose well, you need to know what happens between “move the arm there” and motor current. This section walks both products at the mechanism level, then puts the decision in a matrix.

The MoveIt 2 planning pipeline, step by step

Figure 2: The MoveIt 2 planning pipeline, from request to hardware and back through the planning scene monitor.

A motion plan request enters move_group with a goal, a planning group and constraints. The planning scene monitor supplies the current world: robot joint state, attached objects, collision objects and, if configured, an Octomap from depth sensors. Request adapters then sanity-check the problem. They fix start states that sit slightly outside joint bounds, validate the start is collision-free and apply workspace limits.

The planner plugin solves the geometric problem. OMPL samplers such as RRTConnect are the usual default because they find feasible paths quickly in cluttered spaces. Their output is jagged and non-deterministic, though. Pilz produces predictable industrial moves but can fail outright when a straight line is infeasible. STOMP and CHOMP optimize for smoothness and clearance at the cost of more compute and sensitivity to initialization.

Response adapters then add timing. A geometric path has no velocities; time parameterization turns it into a trajectory that respects velocity and acceleration limits. The trajectory execution manager hands that trajectory to a controller-manager plugin. The plugin sends it to a joint trajectory controller in ros2_control, which interpolates setpoints at the controller rate. Our ros2_control hardware interface tutorial covers the bottom of this stack in detail.

The loop closes when hardware state flows back into the planning scene. If a person steps in after planning, a vanilla pipeline does not replan. You need Servo, hybrid planning or your own monitoring to react.

What 2.15.2 changed and why it matters

The 2.15.2 changes look small but map directly onto that pipeline. The headline change, from moveit/moveit2#3851, gives controller spawners a parameter file. It touches moveit_configs_utils, moveit_ros_planning, moveit_servo and moveit_hybrid_planning, among others. Controller spawning is where many first-day MoveIt 2 launches fail. A controller that never activates yields a planned trajectory that nobody executes, which looks like a planning bug and is not.

Other fixes: FloatingJointModel::getMaximumExtent() now covers the full rotation range (#3854), which affects mobile bases modeled as floating joints. Logger node teardown now happens before RMW shutdown (#3833), removing a noisy crash-on-exit class. The release also includes boost dependency cleanup, clang-tidy fixes and a setup-assistant include-path export fix (#3844). Companion bumps landed for moveit_resources 3.2.1-1 and picknik_controllers 0.0.5-1.

The practical reading: 2.15.2 is a stabilization release. Upgrade if you ship on Lyrical, rebuild your MoveIt config packages, and re-test controller bring-up specifically. There is also an open community thread on Lyrical/Rolling ament and CMake incompatibilities (moveit/moveit2#3717) worth watching if your workspace builds MoveIt from source.

The MoveIt Pro Objective runtime, step by step

Figure 3: An illustrative MoveIt Pro surface-processing Objective, from operator request to execution status and retry.

The sequence above is a composite of the 9.0 features. It is an illustration of how the pieces fit, not a copy of a PickNik sample. An operator starts an Objective from the UI. The Objective Server ticks the tree, and a capture Behavior requests several depth scans. Perception Behaviors align them with ICP into one surface, filter with 2D masks and bounding boxes, and extract contours. A path Behavior rasterizes the surface into a Cartesian coverage path. Planning Behaviors check it against collision and joint limits and produce a trajectory. Execution reports success or failure back to the tree, which can branch into a retry, a rescan or an operator prompt.

Now count what you would build to do the same in MoveIt 2. You would need a point-cloud pipeline, likely PCL or Open3D; a registration step; a segmentation model; a coverage-path generator; a Cartesian planner call that tolerates partial success; a task supervisor with retries; and a UI. Each is available as open source somewhere. The integration, testing and ownership cost is the real product Pro sells.

Behavior trees: the same idea, different ownership

Behavior trees are not proprietary to Pro. BehaviorTree.CPP is open source, and Nav2 already uses it in the ROS 2 ecosystem. You can build a MoveIt 2 application with a BehaviorTree.CPP supervisor and your own action nodes. Our behavior trees for robot task planning guide walks through that architecture.

The difference is tooling depth. Pro ships a library of prebuilt Behaviors, an integrated editor, a debugger and a runtime that loads Behavior plugins without separate launch files. PickNik’s docs also note a Behavior can be a thin call to a separate ROS node on another machine or container. That is a useful escape hatch for heavy dependencies such as ML frameworks. If you roll your own, you get none of that tooling for free, but you also avoid a runtime you do not control.

One constraint applies to both. Behaviors must not block the tree’s execution flow; long-running work needs its own thread or an asynchronous action. Teams that port blocking Python scripts into tree nodes, in either product, get frozen trees and missed halts.

Decision matrix

The matrix below reflects my assessment of typical fits, not vendor positioning. “Strong” means the product addresses the need out of the box; “Build” means you can get there but must assemble it.

Need or constraint	MoveIt 2.15 open source	MoveIt Pro 9.x/10.x commercial
License and cost	BSD-3-Clause, no fee	Commercial license, pricing via PickNik
ROS 2 distribution	Lyrical Luth: 2.15.x	10.x on Jazzy; Lyrical on roadmap
Core arm planning	Strong: OMPL, CHOMP, STOMP, Pilz	Strong: same planning heritage
Real-time jogging	Strong: MoveIt Servo	Strong: built into teleop
Task sequencing and retries	Build: BehaviorTree.CPP or state machine	Strong: Objective Server and editor
Perception-to-path for surfaces	Build: PCL or Open3D plus coverage planner	Strong: contours, ICP, rasterized paths
Teleop and training-data capture	Build	Strong: redesigned in 9.0
Mobile manipulation	Partial: floating joints, custom glue	Strong: native arms plus wheels
Operator UI	Build: RViz or custom web	Strong: web UI in 9.x, desktop app in 10.x
Learned-policy execution	Build	Strong: VLA and policy interface in 10.0
Source-level control	Full	Limited to extension points
Vendor support	Community, paid consultancies	Vendor support contract
Research and novel planners	Strong: plugin interfaces	Possible, less natural
NVIDIA Jetson	Community builds	Supported under Jazzy in 10.0
Qualcomm Dragonwing optimization	Community-driven, not announced	Announced integration target

A quick heuristic falls out of the table. If three or more “Build” cells in the left column are on your critical path and you have fewer than about five robotics software engineers, Pro’s cost is probably lower than your integration cost. That threshold is my estimate, not a measured figure. If your differentiation is the task layer itself — a novel manipulation skill, a research planner, a proprietary perception stack — keep that layer in your own code on MoveIt 2.

What the Qualcomm Deal Changes, and What It Does Not

Most of the news coverage frames this as an open-source story. The engineering-relevant parts are narrower and more concrete.

What the companies have said

According to The Robot Report, Qualcomm “plans to keep MoveIt 1 and 2 open-source under its existing license and community-driven roadmaps.” It also says it will keep supporting MoveIt on third-party hardware, calling hardware-agnostic design a key enabler. Both PickNik and Qualcomm are founding members of the Open Source Robotics Alliance (OSRA), the Open Robotics initiative that governs ROS projects. Qualcomm also said it intends to continue driving projects such as Space ROS.

The commercial plan is explicit too. MoveIt Pro will be integrated with Dragonwing AI acceleration, heterogeneous compute and real-time capability. The first integration target is the Arduino VENTUNO Q. At ROSCon Toronto the companies demonstrated MoveIt Pro running on VENTUNO Q and Dragonwing hardware.

Three facts need stating plainly. The deal is an agreement to acquire, not a completed acquisition. Closing is subject to customary conditions. The price was not disclosed. Everything about future licensing is a stated plan, not a contractual commitment that outside developers can enforce.

The hardware path: VENTUNO Q and Dragonwing

Figure 4: The announced Qualcomm robotics path, with MoveIt layered on the Arduino VENTUNO Q dual-processor design.

VENTUNO Q is a “dual-brain” board. The application side is a Qualcomm Dragonwing IQ-8275 rated at up to 40 dense TOPS, with 16 GB of LPDDR5, 64 GB of eMMC and M.2 NVMe expansion. It runs Ubuntu from Canonical. The real-time side is an STM32H5 microcontroller running Arduino Core on Zephyr RTOS, handling motors, CAN-FD, PWM and GPIO. The software story includes Arduino App Lab, GGUF models from Hugging Face, Edge Impulse Studio and Qualcomm’s GenieX on-device generative AI runtime. For production, the “Works with Arduino” program points to SECO and Toradex system-on-modules with the same IQ8 chip.

Map that onto Figure 2. The application processor hosts ROS 2, move_group or the Objective Server, perception and AI models. The MCU owns the hard real-time loop. The interesting engineering question is the seam between them: whether ros2_control hardware interfaces talk to the MCU over an internal bus with bounded latency. The public material does not yet specify that integration in detail. Treat it as an open question until reference designs ship.

My analysis: what probably changes

The following is analysis, not company guidance.

First, expect MoveIt Pro to get Qualcomm-specific acceleration before MoveIt 2 does. Perception Behaviors — mask filtering, point-cloud alignment — are the obvious candidates for NPU offload. That is where Pro 9.0 invested, and where 40 TOPS helps.

Second, expect pressure on the GPU-centric alternative. NVIDIA’s Isaac ROS already offers cuMotion as a GPU-accelerated planner that plugs into MoveIt. With the MoveIt steward now inside a chip company, planner-plugin neutrality becomes a governance question OSRA members will watch. The plugin interfaces are open source and hard to close quietly, which is reassuring. It also matters that MoveIt Pro 10.0, released three weeks before the deal was announced, added NVIDIA Jetson support. Whether that support gets the same investment as Dragonwing after closing is the concrete thing to watch.

Third, release cadence is the most likely thing to shift, in either direction. More funded maintainers could speed MoveIt 2 releases. Reprioritization toward commercial Pro work could slow community-facing fixes. The honest answer is that nobody outside the companies knows yet. The 2.15.2 release merged five days before the announcement is at least evidence of active maintenance.

What does not change on day one

Your installed packages do not change. BSD-3-Clause code already released stays BSD-3-Clause; a license cannot be retroactively revoked for versions you already hold. Your MoveIt config packages, planner choices and controller setup keep working on Lyrical exactly as they did last week. MoveIt Pro customers keep their existing contracts until PickNik or Qualcomm says otherwise.

Worked Example: Choosing a Stack for a Surface-Cleaning Cell

Abstract matrices only go so far. Here is a worked, illustrative scenario with labelled estimates.

A startup builds a mobile robot that wipes and disinfects restaurant tables. It has a six-axis arm on a wheeled base, one depth camera on the wrist and three software engineers. The job: scan a table, find its outline, generate a coverage path, wipe it, move to the next table.

On MoveIt 2, the team needs a point-cloud capture node and ICP registration if it takes multiple scans. It needs a table segmenter, a contour extractor and a coverage planner that rasterizes the table into strokes. It also needs a Cartesian path call with partial-success handling, a behavior tree for retries and base motion, and an operator UI. My estimate for three engineers to production quality is two to four quarters, with the perception and coverage pieces taking most of it. MoveIt itself would be a small part of the code.

On MoveIt Pro, whose 9.0 release introduced these surface features, contour extraction, rasterized Cartesian paths, ICP merging, mask filtering, mobile manipulation and the task runtime are built-in features. The team’s work shifts to configuration, custom Behaviors for its wiping tool and fleet integration. My estimate is a quarter or less to a credible pilot, plus license cost.

That scenario sits squarely in Pro’s sweet spot, which is why cleaning and washing firms appear on the 9.0 customer list. Change one variable and the answer flips. Suppose the startup’s edge is a novel learned wiping policy that needs custom planner behavior and tight control over trajectories. Then owning the stack on MoveIt 2 may be worth the extra quarters. The deciding factor is where differentiation lives, not which product has more features.

Now add the deal. If the startup was already considering Qualcomm silicon for cost or power, Pro on VENTUNO Q-class hardware becomes the most integrated path on paper. If it is committed to NVIDIA Jetson for its learned policy, both options work today: MoveIt Pro 10.0 supports Jetson under Jazzy. The open core still has the edge on neutrality, because there it is structural rather than a vendor roadmap decision.

Trade-offs, Gotchas, and What Goes Wrong

Both products fail in characteristic ways. Knowing them saves weeks.

MoveIt 2 failure modes. The most common first-week failure is controller bring-up: spawners that never activate, mismatched controller names between the MoveIt config and ros2_control, or wrong action namespaces. The 2.15.2 spawner parameter-file change targets exactly this. Second is planner mismatch. Teams use OMPL for moves that should be Pilz LIN motions, then fight non-deterministic paths near fixtures. Third is stale planning scenes. Octomap updates lag fast-moving obstacles, and a plan valid at request time is invalid at execution. Without Servo or hybrid planning, nothing reacts. Fourth is time parameterization surprises, where smoothed trajectories violate a joint’s real acceleration limit because URDF and controller limits disagree.

MoveIt Pro failure modes. The common failure is abstraction mismatch: forcing a task the Behavior library does not model into a tree full of workaround nodes. A second is blocking Behaviors, which freeze the tree and ignore halts. A third is organizational. Task knowledge accumulates inside Objectives stored in a vendor format and runtime, which raises switching costs every quarter. The XML is BehaviorTree.CPP format, which helps portability, but the prebuilt Behaviors those trees call are not open source.

Acquisition-specific risks. Roadmap drift toward Dragonwing-first features is plausible for Pro. For MoveIt 2, the risk is subtler: maintainer attention, not license. Open source rarely dies by relicensing; it more often slows when paid maintainers get redirected. A useful indicator is PR review latency on moveit/moveit2 over the next two or three release cycles.

Hardware-integration risk. Dual-processor boards move the real-time loop onto an MCU. That is sound design, but it adds a latency-sensitive boundary between trajectory controllers and actuators. Until reference ros2_control integrations for VENTUNO Q are public and measured, budget time to characterize jitter yourself.

Anti-patterns. Do not treat Pro as a planning upgrade if planning is not your bottleneck. Do not fork MoveIt 2 to add application features that belong in your own packages. And do not write architecture decisions this week that assume either the most optimistic or most pessimistic reading of the deal.

Practical Recommendations

For most ROS 2 manipulation teams, the right move this quarter is to make the task-layer boundary explicit, upgrade to MoveIt 2.15.2 if you ship on Lyrical, and avoid deal-driven replatforming. Pro makes sense when perception-to-path, teleoperation or mobile manipulation is on your critical path and headcount is small. The open core makes sense when your differentiation is the task or planning logic itself.

Mind the distribution gap. Open-source MoveIt ships 2.15 on Lyrical, but MoveIt Pro 10.x requires Jazzy, with Lyrical support only on its roadmap. A team that has just migrated to Lyrical and then adopts Pro may need to run Jazzy for the Pro stack until PickNik ships Lyrical support.

For planning-layer comparisons against other open frameworks, our MoveIt 2 vs Tesseract analysis is the companion to this post.

Checklist:

• [ ] Upgrade Lyrical workspaces to MoveIt 2.15.2-1 and rebuild MoveIt config packages.
• [ ] Re-test controller spawning and action namespaces after upgrading.
• [ ] Write down who owns your task layer: your code, MoveIt Pro, or a mix.
• [ ] If evaluating MoveIt Pro, check the ROS 2 distribution: 10.x requires Jazzy today.
• [ ] Count the “Build” cells from the decision matrix on your critical path.
• [ ] Keep application logic out of forks; use plugins, Behaviors and separate packages.
• [ ] If on Pro, keep custom Behaviors thin and push heavy logic into ROS nodes you own.
• [ ] Track moveit/moveit2 release cadence and review latency over the next few cycles.
• [ ] Characterize real-time latency yourself before committing to any new dual-processor board.
• [ ] Revisit this decision when the acquisition closes or licensing terms are published.

Frequently Asked Questions

What is the difference between MoveIt 2 and MoveIt Pro?

MoveIt 2 is the open-source, BSD-3-Clause motion-planning framework for ROS 2. It provides move_group, planner plugins such as OMPL, CHOMP, STOMP and Pilz, MoveIt Servo, hybrid planning and Python bindings. MoveIt Pro is PickNik’s commercial application platform. It adds a behavior-tree Objective runtime, an operator UI, perception-to-motion pipelines, teleoperation, training-data collection, learned-policy execution and whole-body mobile manipulation. The current 10.x line runs on ROS 2 Jazzy, while open-source MoveIt 2.15 ships in Lyrical. In short, MoveIt 2 is a library you integrate into your own application, while MoveIt Pro is a platform you build applications inside.

Is Qualcomm going to make MoveIt closed source?

Qualcomm has said it plans to keep MoveIt 1 and 2 open source under the existing license, with community-driven roadmaps, and to keep supporting third-party hardware. That is a stated intent, and the deal had not closed at announcement. Versions already released under BSD-3-Clause stay under that license regardless, because released open-source licenses cannot be revoked for existing copies. The realistic risk is not relicensing but shifts in maintainer attention, which you can monitor through release cadence and pull-request review times.

What is new in MoveIt Pro 9.0?

MoveIt Pro 9.0, announced April 2, 2026, focused on perception-to-motion and teleoperation. It added automated contour extraction with rasterized Cartesian path generation from point clouds, AI-driven 2D mask filtering and bounding-box analysis, and ICP point-cloud alignment for merged scans. It also brought whole-body motion control with collision checking and joint-limit enforcement, native mobile manipulation, and redesigned teleop and data collection with multi-arm support. The UI now supports up to six resizable panes, up from four. Note that 9.0 is no longer the newest line: MoveIt Pro 10.0 shipped on September 1, 2026, requiring ROS 2 Jazzy and adding learned-policy execution, a desktop app and NVIDIA Jetson support.

Which MoveIt version ships with ROS 2 Lyrical Luth?

ROS 2 Lyrical Luth ships the MoveIt 2.15 line. On September 18, 2026, rosdistro PR #53995 updated Lyrical to MoveIt 2.15.2-1 from 2.15.1-1. The release focuses on controller spawning: spawners now take a parameter file across several packages. It also fixes a floating-joint extent bug, logger teardown ordering at shutdown and a setup-assistant include path. Companion updates bumped moveit_resources to 3.2.1-1 and picknik_controllers to 0.0.5-1. The rosdistro reviewer merged it after judging that the changes did not break API or ABI.

Can I run MoveIt on Arduino VENTUNO Q?

VENTUNO Q is announced as the first MoveIt integration target, and PickNik and Qualcomm demonstrated MoveIt Pro on it at ROSCon Toronto. The board pairs a Dragonwing IQ-8275 application processor running Ubuntu with an STM32H5 microcontroller on Zephyr RTOS for motor control. Because it runs Ubuntu, a standard ROS 2 and MoveIt 2 installation is plausible. However, published reference integrations and measured real-time performance were not available at announcement, so validate latency before committing.

Should I switch from MoveIt 2 to MoveIt Pro because of the acquisition?

Not because of the acquisition alone. Switch if perception-to-path, teleoperation, mobile manipulation or task sequencing is on your critical path and your team is too small to build and maintain those layers. Stay on the open core if your differentiation is the task or planning logic, or if you need hardware neutrality across vendors such as NVIDIA. Revisit the decision when the deal closes and when concrete Pro-on-Dragonwing features and licensing terms are published, rather than acting on announcements.

Further Reading

• MoveIt 2 vs Tesseract: robot motion planning frameworks compared
• ROS 2 Kilted to Lyrical Luth migration guide
• ros2_control hardware interface tutorial
• Behavior trees for robot task planning architecture
• MoveIt 2.15.2 Lyrical release pull request on rosdistro
• MoveIt Pro behavior tree concepts in PickNik’s documentation

By Riju — about