MoveIt Pro 10.0 vs 9.4: The Breaking Upgrade Guide

Every fleet operator running PickNik’s motion-planning stack eventually hits the same wall: a release note that looks routine until you read past the headline. MoveIt Pro 10.0 vs 9.4 is one of those releases — it is not an incremental bump, it is a platform cut. ROS 2 Humble support ends, a dozen Behaviors are renamed or removed outright, core Docker images and services change their names, and the product gains an entirely new execution mode for vision-language-action (VLA) policies. If your CI pipeline, Objective library, and deployment scripts were written against 9.4, several of them will fail silently or loudly the moment you point them at a 10.0 Runtime.

This guide walks through what actually changed between the 9.4 line and the 10.0/10.1 releases, why PickNik made the cut now, and how to sequence a migration without stranding a production cell mid-shift.

What this covers: the platform and OS requirements that force the upgrade, every Behavior rename and removal we could verify, the infrastructure-level renames (images, services, credentials, packages), the new VLA policy execution pipeline, and a practical checklist for moving a 9.4 workspace to 10.0 or 10.1 without breaking Objectives in production.

Context and Background

MoveIt Pro is PickNik Robotics’ commercial, production-hardened distribution built on top of the open-source MoveIt 2 motion-planning framework. Where MoveIt 2 gives you a planning library and a set of ROS 2 interfaces, MoveIt Pro wraps that library in a Behavior-Tree authoring environment, a Runtime service, a web-based operator UI, and — as of 10.0 — a native desktop application. If you’re new to the split between the open-source core and PickNik’s packaged product, our existing comparison covers that ground in depth; this piece assumes you already run MoveIt Pro in some capacity and need to move a 9.x deployment forward.

The upgrade path this guide covers is narrow but consequential: MoveIt Pro 9.4.2, released 2026-08-31, was the last release in the 9.x line before PickNik shipped MoveIt Pro 10.0.0 on 2026-09-01 — a same-week cutover that left almost no overlap window. A follow-up release, 10.1.0, landed 2026-09-18 and added its own breaking change on top of 10.0’s list. PickNik publishes a dedicated official document, “Migrate User Workspace From 9.x to 10.0,” in its docs; this article summarizes the breaking-change surface and the reasoning behind it, but you should treat that official guide as the source of truth for exact CLI invocations and workspace file diffs.

It’s worth noting that 9.4.2 already dropped hints of what was coming: PickNik pulled FFmpeg and other GPL-licensed codec libraries, removed the usb_cam driver from the Runtime image, and switched OpenCV to a GStreamer backend — all in a release with no breaking changes documented for end users. Those quiet removals compound directly into 10.0’s camera and streaming changes, discussed below. If you were watching the changelog closely, the platform break didn’t come out of nowhere.

For teams evaluating whether MoveIt Pro is still the right layer above MoveIt 2 for their use case — versus, say, a lower-level planning stack — our MoveIt 2 vs Tesseract comparison is a useful companion read, since the trade-offs between a managed commercial distribution and a bare planning library resurface every time a major version forces a re-evaluation.

One more piece of context matters before you touch a production Runtime: a MoveIt Pro deployment isn’t a single artifact you swap out — it’s a workspace made up of Objective definitions, custom Behavior packages, Docker Compose or Kubernetes manifests, credential secrets, and often a fork of one or more PickNik-provided base packages. The official 9.x-to-10.0 migration guide is scoped to walk through that workspace layer by layer rather than treating the upgrade as a single apt or docker pull operation, and that scoping is a reasonable signal of how much surface area actually changed. Don’t let the phrase “migration guide” undersell the amount of validation work involved; it’s closer in scope to a platform re-platforming than a dependency bump.

Why This Upgrade Forces a Platform Change, Not Just a Package Bump

Direct answer: MoveIt Pro 10.0 requires ROS 2 Jazzy Jalisco and drops ROS 2 Humble entirely, because Humble reaches end of life in May 2027 and PickNik wanted a longer support runway before that clock ran out; Jetson deployments additionally require JetPack 7.2, Ubuntu 26.04 is newly validated, and Ubuntu 22.04 support is dropped, while ROS 2 Lyrical support is only “planned for later in the 10.x line” — meaning Jazzy is the only fully-supported target today.

This is the detail that trips up teams who treat MoveIt Pro upgrades like npm version bumps. A 10.0 install is not something you can drop into an existing 9.4 host OS. If your Runtime machines are still on Ubuntu 22.04 with ROS 2 Humble — which describes a large share of MoveIt Pro fleets deployed over the last two years — the 10.0 upgrade path runs through an OS reimage, not a apt upgrade. PickNik’s own justification is straightforward: Humble’s end-of-life date is fixed, and shipping a major feature release (VLA execution, the desktop app, MCP server integration) on a ROS 2 distribution with roughly six months of remaining support left the company exposed to supporting two long-tail distributions simultaneously. Cutting Humble now, while Jazzy has years of runway left, is the more defensible engineering call even though it front-loads pain onto existing fleets.

The Jetson requirement compounds this. JetPack 7.2 is itself a substantial platform revision on NVIDIA’s side, and fleets running embedded compute on older Jetson modules will need to validate that their specific module (Orin, Xavier, or newer) has a JetPack 7.2 image before they can even attempt the MoveIt Pro upgrade. Teams running mixed fleets — some cells on x86 Runtimes, some on Jetson-based edge compute — should expect the Jetson leg of the migration to take longer than the x86 leg, simply because JetPack upgrades on embedded hardware carry more physical-access and reflashing overhead than a server OS reimage.

There’s a smaller but real win buried in the platform requirements: MoveIt Pro 10.0 adds AMD GPU support for rendering and simulation workloads, which matters for shops that standardized on AMD compute for cost or supply-chain reasons. The caveat is that ML inference — the actual VLA model forward passes — still falls back to CPU on AMD hardware. If your VLA execution plans assumed AMD GPUs would carry inference load, plan for CPU-bound inference latency instead, or budget for an NVIDIA inference node alongside AMD render nodes.

Figure 1: A migration decision flow showing the OS and Jetson checks that gate a 9.4-to-10.0 upgrade, followed by Behavior and infrastructure audits before a staged simulation validation and production promotion. Long description: the flow starts at MoveIt Pro 9.4.2, branches on whether the host runs ROS 2 Humble (requiring an OS and ROS 2 Jazzy upgrade) or is already on Jazzy, then checks for Jetson hardware (requiring a JetPack 7.2 flash), before converging on a Behavior and infrastructure audit, a staged install of 10.0 or 10.1, simulation validation, and a go/no-go gate back to the audit step on failure.

The 10.0 Feature Set That Justifies the Break

PickNik didn’t cut Humble support purely for maintenance-burden reasons — 10.0 ships enough new surface area that a platform-level reset makes sense as a packaging decision. The headline additions:

• A native desktop application (signed, Linux-first, with macOS and Windows listed as “coming soon”) that auto-discovers Runtimes on the local network, replacing or supplementing the browser-based operator UI for local development.
• VLA policy execution as continuous, collision-checked motion. Rather than treating a vision-language-action model’s output as a one-shot trajectory, MoveIt Pro 10.0 blends each new batch of predicted actions onto the trajectory already running on the robot, so a policy can be corrected mid-motion without a full stop-and-replan cycle.
• Built-in training-data collection, where operator demonstrations recorded through the desktop app or teleop interface are automatically converted to LeRobot format — the dataset schema that’s become a de facto standard across the open VLA ecosystem.
• A train-model skill that fine-tunes VLA models against your own collected dataset using Runpod’s cloud GPUs, meaning teams without local training hardware can still iterate on policies.
• Meta Quest controller teleoperation, with clutch-based following for repositioning without moving the robot and trigger-based gripper control — a meaningfully lower-friction data-collection workflow than keyboard or joystick teleop.
• An MCP (Model Context Protocol) server, letting coding agents like Claude inspect Objectives, Behaviors, Waypoints, and live robot state over an authenticated local or remote connection — a detail worth flagging for teams already building agent-assisted robotics tooling, since it’s a first-class integration point rather than a bolt-on API.

Any one of these would justify a minor release. Together, shipped simultaneously with a platform floor raise, they explain why PickNik treated 10.0 as a clean break rather than a gradual Humble-to-Jazzy deprecation window.

The MCP server addition deserves a second look from an operations perspective, not just a developer-tooling one. Giving a coding agent authenticated read access to Objectives, Behaviors, Waypoints, and live robot state — whether over a local or remote connection — is a meaningful expansion of the attack surface around a Runtime, even when the intent is purely to speed up development and debugging. Teams standing up 10.0 or 10.1 in a networked, multi-cell environment should treat the MCP server the same way they’d treat any other authenticated remote interface: scope its credentials narrowly, keep it off any network segment that isn’t already trusted for Runtime access, and don’t assume “it’s just for coding assistants” means it carries lower risk than the operator web UI it sits alongside. The same applies to the desktop app’s network auto-discovery of Runtimes — convenient in a lab, worth firewalling deliberately once cells are on a shared production network.

Breaking Changes Walk-through: Behaviors, Images, and Infrastructure

The feature list is the easy part to get excited about. The part that will actually break your Objectives on upgrade day is the Behavior and infrastructure rename surface, and this is where teams underestimate the migration effort. PickNik removed some Behaviors outright with no aliasing, renamed others while keeping deprecated aliases active “for now,” and renamed infrastructure components — Docker images, services, credentials, and ROS packages — with no aliasing at all.

Start with what’s gone for good. Several Behaviors were removed rather than renamed, meaning any Objective referencing them will fail to load until you swap in the replacement:

Removed in 9.4 → 10.0	Replacement	Migration note
ExecuteMTCTask	ExecuteMTCSolution	Not a straight swap — check parameter names, since the solution-based Behavior consumes a different upstream artifact than the task-based one did.
Legacy GraspableObject-based collision Behaviors	None documented	These need to be rebuilt against the current collision-object model; there is no drop-in successor named in PickNik’s release notes.
ExecuteFollowJointTrajectory	ExecuteTrajectory	Consolidated.
ExecuteTrajectoryWithAdmittance	ExecuteTrajectory	Consolidated — admittance behavior is now a parameter path on the unified Behavior rather than a separate Behavior class.
CLIPSeg segmentation	SAM3	If your perception pipeline was tuned around CLIPSeg’s prompt behavior, expect to re-tune prompts and thresholds against SAM3’s segmentation output.
DiffusionPolicy	ExecutePolicy	This is the Behavior most directly tied to the new VLA execution model — see the section above.
GetGraspPoseFromPointCloud	None documented	Flag for manual review; no direct successor is named.

Two of these — the removed GraspableObject collision Behaviors and GetGraspPoseFromPointCloud — have no documented replacement in the source material for this article. If your Objective library uses either, don’t assume a same-named or obviously-adjacent Behavior exists in 10.0; verify directly against PickNik’s Behavior reference before you plan the swap.

Separately, seven joint-state-related Behaviors were renamed, not removed — the old names remain active as deprecation aliases for now, which buys you time but not indefinitely. The two confirmed examples are GetRobotJointState → GetJointState and CreateJointState → CreateRobotState. PickNik’s release notes describe five additional renames in this same family beyond these two; we’re not going to guess at their exact names here, because getting a Behavior identifier wrong in a migration guide is worse than leaving a gap — pull the complete joint-state rename list from the official 9.x-to-10.0 migration guide before you script a bulk find-and-replace across your Objective files.

Figure 2: A mapping of Behaviors removed or renamed between 9.4 and 10.0, showing which old Behaviors consolidate into a single new one, which map one-to-one, and which have no documented replacement. Long description: ExecuteMTCTask maps to ExecuteMTCSolution; ExecuteFollowJointTrajectory and ExecuteTrajectoryWithAdmittance both map into the consolidated ExecuteTrajectory; CLIPSeg Segmentation maps to SAM3 Segmentation; DiffusionPolicy maps to ExecutePolicy; GetGraspPoseFromPointCloud and the legacy GraspableObject collision Behaviors both terminate at a node marked removed with no direct replacement; GetRobotJointState maps to GetJointState and CreateJointState maps to CreateRobotState as renamed pairs.

Infrastructure Renames: Images, Services, Credentials, Packages

The Behavior-level changes are visible the moment an Objective fails to load. The infrastructure-level renames are more dangerous precisely because they fail quietly — a deployment script that references an old Docker image tag or environment variable name will often fail with a generic “not found” error that doesn’t obviously point back to the version upgrade as the cause.

Component	9.4 name	10.0 name	Change type
Docker image	moveit-studio	moveit-pro	Renamed
Core service	agent_bridge	runtime	Renamed
Credential env var	MOVEIT_API_KEY	MOVEIT_FRONTEND_KEY	Renamed
ROS package	cartesian_planning	path_ik	Renamed
Planner	STOMP	—	Removed (was non-functional)
Custom message	RobotJointState (custom msg)	moveit_msgs/RobotState (standard)	Replaced with standard message
Compatibility package	moveit_studio_common	—	Removed
API endpoint	Legacy rosbridge endpoint	—	Removed
Video codec	H.264	VP8 (required for WebRTC)	Removed / replaced
Streaming transport	MJPEG	WebRTC	Replaced for lower latency
Media libraries	FFmpeg, OpenH264	—	Removed from Runtime image

Two of these deserve extra attention because they’re the ones most likely to break CI or deployment automation silently. First, the MOVEIT_API_KEY → MOVEIT_FRONTEND_KEY rename isn’t cosmetic — PickNik paired it with a broader security change in 10.0 where web endpoints now require a shared frontend key, and the Desktop App verifies Runtime TLS certificates before it will send credentials at all. If your existing deployment injects MOVEIT_API_KEY as a secret through Kubernetes, Ansible, or a CI variable, that secret name needs to be renamed and re-validated, not just left in place as a harmless unused variable — because unlike the joint-state Behavior renames, there’s no alias here.

Second, the camera and media stack change is a bigger operational shift than the table implies. Camera streaming moved from MJPEG to WebRTC specifically for lower latency, which is a genuine improvement for teleoperation and live monitoring — but it requires VP8 encoding, and PickNik removed FFmpeg and OpenH264 from the Runtime image entirely to get there (following the same removals that started quietly in 9.4.2). If you have custom camera integration code, recording pipelines, or third-party monitoring tools that assumed an FFmpeg binary was available inside the Runtime container, that assumption breaks in 10.0. Teams that built custom video recording or transcoding sidecars against the old MJPEG/FFmpeg pipeline should expect to rebuild that integration against WebRTC/VP8 rather than patch it.

Figure 3: A before-and-after comparison of MoveIt Pro’s core infrastructure components across the 9.4-to-10.0 boundary. Long description: six paired nodes show the moveit-studio Docker image renamed to moveit-pro, the agent_bridge service renamed to runtime, the MOVEIT_API_KEY credential renamed to MOVEIT_FRONTEND_KEY, the cartesian_planning package renamed to path_ik, the STOMP planner removed with no successor, and the MJPEG-over-FFmpeg streaming stack replaced by WebRTC over VP8.

10.1.0: A Second Breaking Change Seventeen Days Later

Teams that plan a migration straight to “10.0” and stop tracking the changelog will miss a second breaking change that landed just over two weeks later. MoveIt Pro 10.1.0, released 2026-09-18, is mostly an additive release — per-joint planning costs, extended collision padding to world objects and attached bodies, a translucent “collision ghost” rendering of the robot in the 3D visualizer on rejected motions, IK failure messages that now name the specific colliding bodies, and live Objective authoring added to the MCP server. All genuinely useful debugging and authoring improvements.

But 10.1.0 also changed the default trajectory blend deviation from 0.1 to 0.05 — a breaking change for any Objective or Behavior configuration that relied on the previous default rather than setting the value explicitly. If your motion tuning was implicitly depending on the 0.1 default, trajectories will blend more tightly (less deviation tolerance) after upgrading to 10.1, which can manifest as motions that look “stiffer” or trigger replanning in situations that previously blended through smoothly. 10.1.0 also removed test-only ROS packages from the Runtime image, which is unlikely to affect production Objectives but can break CI pipelines that were (incorrectly) depending on test package availability inside the production Runtime image.

The practical takeaway: don’t treat “upgrade to 10.0” and “upgrade to 10.1” as the same migration event with two version numbers. If you’re planning the move now, go straight to 10.1.0 rather than staging through 10.0.0, but audit your trajectory blend deviation settings specifically as part of that move — explicitly set the value in your Behavior configuration rather than relying on the default, regardless of which version you land on, so the next default change doesn’t silently retune your motions again.

This also has implications for how you test the migration. A staging validation pass that only checks “does the Objective load and execute without error” will pass on a trajectory that’s now blending more tightly than it did under 9.4’s defaults, because a tighter blend deviation doesn’t throw an exception — it changes the shape of the motion. If your validation criteria are limited to load-and-execute success rather than motion-quality comparison against a recorded baseline, you can ship a 10.1 upgrade that “passes” CI while quietly changing cycle time or introducing replanning events on cells where the previous 0.1 deviation was doing useful work smoothing over minor path irregularities. Where you can, capture trajectory execution logs from your 9.4 baseline before cutover, so you have something concrete to diff against after the upgrade rather than relying on operator intuition that “something feels different.”

Trade-offs, Gotchas, and What Goes Wrong

The single biggest trade-off in this release is one PickNik made deliberately: breadth of new capability versus continuity for existing fleets. VLA policy execution, the desktop app, and MCP integration are all substantial, forward-looking additions — but shipping them required a platform floor raise that turns what would normally be a routine minor-version upgrade into a project with OS-reimage-level scope for any fleet still on Humble or Ubuntu 22.04. If your organization runs dozens of Runtime hosts across physical sites, budget real calendar time for the OS and JetPack legs of this migration; they are not scriptable the way a pip install --upgrade is.

The second gotcha is aliasing inconsistency. PickNik kept deprecation aliases for the seven joint-state Behavior renames, which is the right call and gives you a soft landing there. But it did not extend that courtesy to the removed Behaviors (ExecuteMTCTask, GetGraspPoseFromPointCloud, the GraspableObject-based collision Behaviors) or to any of the infrastructure renames (Docker image, service, credential, package names). Teams that test their migration only against a representative sample of Objectives — rather than the full library — risk missing a rarely-invoked Objective that still calls a fully-removed Behavior, and that failure won’t surface until the Objective is triggered in production.

Third, the camera and streaming stack change is a real functional trade-off, not just a rename. WebRTC over VP8 is lower-latency than MJPEG for live teleoperation, which is a genuine win for the new Quest-controller teleop workflow. But if your monitoring or recording infrastructure was built around MJPEG’s simplicity — many off-the-shelf NVR and monitoring tools consume MJPEG natively and don’t speak WebRTC — you may need a bridging component or a rebuilt integration, and that work isn’t optional if continuous recording is a compliance requirement in your deployment.

Finally, be honest with yourself about the VLA execution feature specifically. Continuous, collision-checked blending of policy-predicted actions onto a running trajectory is architecturally interesting, but PickNik’s own material describes it in terms of the mechanism (“each batch of predicted actions is blended onto the trajectory already running”) without publishing head-to-head accuracy or safety benchmarks against the previous DiffusionPolicy Behavior. Treat 10.0/10.1’s VLA execution as a capability worth piloting in a controlled cell before it touches a production line, not as a drop-in upgrade to whatever policy-execution setup you had running before — because there wasn’t a comparable setup running natively before; DiffusionPolicy and ExecutePolicy are not equivalent Behaviors with a renamed label, they represent different execution models.

There’s also a rollback problem worth naming plainly: this migration is much easier to plan forward than to reverse. Once Objectives have been rewritten against ExecuteMTCSolution, ExecuteTrajectory, and SAM3-based segmentation, and once infrastructure manifests reference moveit-pro, runtime, and MOVEIT_FRONTEND_KEY, reverting a cell to 9.4 after a failed cutover means reverting all of that in lockstep with an OS and ROS 2 downgrade — not just reinstalling an older package. Keep your pre-migration workspace, Objective library, and deployment manifests in version control as a tagged, restorable state before you start, and treat the OS-level change as the harder-to-reverse half of the rollback, since re-flashing a fleet of Jetson modules back to an older JetPack image under time pressure is not a fast operation.

Figure 4: The end-to-end VLA policy pipeline introduced in MoveIt Pro 10.0, from operator demonstration through cloud fine-tuning to collision-checked execution on the robot. Long description: an operator records a teleoperated demonstration through the desktop app, which auto-converts the session to LeRobot format and hands it to the Runtime; the Runtime fine-tunes a policy via the train-model skill on a Runpod cloud GPU and receives a trained checkpoint; during execution, the Runtime repeatedly requests predicted action batches from the VLA model, blends each batch onto the trajectory already running on the robot, and receives collision-check feedback before executing the next collision-checked motion segment.

Practical Recommendations

Treat this as a platform migration project, not a version bump, and sequence it accordingly:

• Inventory before you touch anything. Grep your entire Objective library for the removed Behaviors (ExecuteMTCTask, ExecuteFollowJointTrajectory, ExecuteTrajectoryWithAdmittance, CLIPSeg-based segmentation nodes, DiffusionPolicy, GetGraspPoseFromPointCloud, legacy GraspableObject collision Behaviors) and for the infrastructure identifiers (moveit-studio, agent_bridge, MOVEIT_API_KEY, cartesian_planning) across Objective files, deployment scripts, CI configs, and Kubernetes manifests. A text-search inventory takes an afternoon and will surface most of the risk before you commit to a cutover date.
• Pull the full joint-state rename list from PickNik’s official migration guide before scripting any bulk rename — this article confirms two of the seven renames, and guessing at the rest risks introducing new bugs rather than fixing old ones.
• Stage the OS and Jetson upgrades separately from the MoveIt Pro upgrade itself. Get every Runtime host onto Ubuntu 24.04 with ROS 2 Jazzy (and JetPack 7.2 where applicable) as its own validated milestone before installing MoveIt Pro 10.0/10.1 on top. Treating these as two projects with two go/no-go gates, rather than one combined change window, makes it far easier to isolate whether a post-upgrade problem is a platform issue or a MoveIt Pro configuration issue.
• Go straight to 10.1.0, not 10.0.0, but explicitly set your trajectory blend deviation parameter rather than relying on the default — the default changed once already between these two releases, and an implicit default is a liability the next time PickNik retunes it.
• Rebuild any custom camera, recording, or monitoring integration against WebRTC/VP8 before cutover; don’t assume FFmpeg-based tooling will keep working inside the Runtime image, and check third-party NVR or monitoring tools for WebRTC ingestion support ahead of time rather than discovering the gap after cutover.
• Rotate MOVEIT_API_KEY references to MOVEIT_FRONTEND_KEY in every secrets store and re-verify Runtime TLS certificates, since the Desktop App now checks them before sending credentials.
• If you’re standing up the MCP server, scope its network exposure deliberately. Treat it like any other authenticated interface onto live robot state, not a low-risk developer convenience, and keep its credentials separate from operator UI credentials.
• Pilot VLA policy execution in an isolated cell with full collision-ghost visualization enabled (10.1’s new debugging feature) before trusting it on a production line — it is a new execution model, not a renamed version of DiffusionPolicy.
• Run your full Objective library against a staging 10.1 Runtime in simulation before promoting any production Runtime, specifically to catch the un-aliased Behavior removals that won’t show up in casual spot-checks, and capture trajectory execution baselines beforehand so a changed blend deviation shows up as a measurable diff rather than an operator’s hunch.
• Keep a tagged, version-controlled snapshot of your entire pre-migration workspace — Objectives, custom Behavior packages, manifests, and secrets structure — so a rollback decision doesn’t turn into an archaeology project under production pressure.

Frequently Asked Questions

Can I upgrade directly from MoveIt Pro 9.4 to 10.1, or do I need to pass through 10.0 first?

You can go directly to 10.1.0 — it’s not gated behind installing 10.0.0 first. In fact, going straight to 10.1 is the better default, since it includes debugging improvements (collision-ghost visualization, IK failure messages naming colliding bodies) that make validating your migration easier. Just remember that 10.1 carries its own breaking change on top of everything 10.0 introduced: the default trajectory blend deviation dropped from 0.1 to 0.05, so audit that setting regardless of which version you land on.

Do I have to upgrade to ROS 2 Jazzy before I can install MoveIt Pro 10.0?

Yes. MoveIt Pro 10.0 requires ROS 2 Jazzy and does not support ROS 2 Humble at all — there’s no compatibility mode or side-by-side install path documented. Since Humble reaches end of life in May 2027, PickNik cut it now rather than maintaining two ROS 2 distributions through the 10.x line. If your Runtime hosts are still on Humble, plan the ROS 2 and OS upgrade as a prerequisite milestone, completed and validated before you attempt the MoveIt Pro upgrade itself.

What happens to Objectives that still use ExecuteMTCTask after I upgrade?

They will fail to load or execute, because ExecuteMTCTask was removed in 10.0 with no deprecation alias — unlike the joint-state Behavior renames, there’s no soft landing here. You need to migrate those Objectives to ExecuteMTCSolution before upgrading, and you should not assume it’s a pure rename: verify the parameter interface, since a solution-based Behavior consumes a different upstream artifact than a task-based one. Test each migrated Objective in simulation before it touches a production Runtime.

Is the new VLA policy execution feature a replacement for DiffusionPolicy?

Not directly, even though DiffusionPolicy was removed and ExecutePolicy is named as its replacement Behavior. The underlying execution model changed: 10.0 blends each batch of predicted actions onto the trajectory already running on the robot, as continuous, collision-checked motion, rather than treating a policy’s output as a single trajectory to execute. Treat this as a new capability to pilot and validate, not a drop-in swap for whatever policy-execution workflow you had running under DiffusionPolicy.

Will my camera and video recording setup keep working after the upgrade?

Only if it doesn’t depend on FFmpeg, OpenH264, or MJPEG streaming — all three are removed from the MoveIt Pro 10.0 Runtime image, following removals that actually started quietly in 9.4.2. Camera streaming now uses WebRTC over VP8 for lower latency. If you built custom recording, transcoding, or monitoring integrations against the old pipeline, plan to rebuild them against WebRTC/VP8 rather than expecting the old tooling to keep functioning inside the new Runtime container.

Does the MOVEIT_API_KEY to MOVEIT_FRONTEND_KEY rename affect existing automation and CI pipelines?

Yes, and it’s one of the easiest breaking changes to miss because it fails as a generic authentication error rather than an obvious version-mismatch error. Any script, CI job, or deployment manifest that injects MOVEIT_API_KEY as a secret needs to be updated to MOVEIT_FRONTEND_KEY. This rename is paired with a broader security change in 10.0: web endpoints now require the shared frontend key, and the Desktop App verifies Runtime TLS certificates before sending credentials at all, so treat this as a credentials-and-certificate audit, not just a variable rename.

How hard is it to roll back to MoveIt Pro 9.4 if the 10.x migration goes badly mid-cutover?

Harder than most teams expect, which is why rollback planning belongs at the start of the project, not as an afterthought. A rollback isn’t just reinstalling an older Docker image — it means reverting Objectives that reference renamed or removed Behaviors, restoring the old MOVEIT_API_KEY-based credential flow, and downgrading the host OS and ROS 2 distribution, plus re-flashing Jetson modules back to their prior JetPack version if you’d already upgraded them. Keep a version-controlled, tagged snapshot of your full 9.4 workspace and deployment manifests before you start, and treat the OS/Jetson layer as the slowest part of any rollback to execute under time pressure.

Further Reading

• MoveIt 2 vs MoveIt Pro: Qualcomm, PickNik, and the commercial layer
• MoveIt 2 vs Tesseract: comparing robot motion-planning stacks
• ROS 2 Kilted to Lyrical: navigating the distribution migration path
• VLA models compared: GR00T, Gemini Robotics, and Pi0
• PickNik Robotics, MoveIt Pro release notes and migration documentation — docs.picknik.ai/release-notes
• Open Robotics, ROS 2 Humble Hawksbill end-of-life schedule — docs.ros.org
• Hugging Face, LeRobot dataset format documentation — huggingface.co/docs/lerobot

By Riju — about