Community Group Proposal: Automated ROS Upgrade Assistant

ROS ROS General
, , , ,
1

Hello everyone,

I would like to start a community discussion around building an AI-assisted ROS migration and upgrade tool focused on ROS 2 LTS transitions such as:

  • Humble → Jazzy

  • Jazzy → Lyrical

As ROS 2 adoption grows, many developers face challenges upgrading between releases due to API changes, deprecated interfaces, package compatibility issues, launch system updates, Nav2 migration challenges, QoS behavior differences, build system adaptations, and CI/CD validation changes.

The goal is not only syntax conversion, but practical engineering support for production migrations.

I would like to explore:

  • Upgrade analysis tooling

  • Automated migration suggestions

  • Compatibility validation

  • Package dependency checking

  • Launch file migration assistance

  • Nav2-specific upgrade support

I am looking for contributors interested in ROS core development, Nav2, tooling, developer experience, and AI-assisted code migration.

If there is enough interest, we can organize a community group discussion and eventually work toward a formal proposal.

I would especially appreciate feedback from @smac , @mjcarroll, and @katherine_Scott, along with others working on ROS 2 migration workflows and developer tooling.

Would love to hear thoughts from the community.

Best,
Darshil

3 Likes
ROS News for the Week of April 20th, 2026
ROS News for the Week of April 27th, 2026
2

Just rambling a few thoughts here off the top of my head:

  • For a project like this we would probably want some degree of “AI platform independence.” That is to say a way to replicate the results (with varying degrees of reliability) across all of the AI vendors. I think picking a particular winner (e.g. ChatGPT, Claude, Co-pilot, a FOSS model) is probably a losing proposition. Having said that, getting one vendor to work well, followed by adding successive, vendors is probably the way to go.
  • The ability to do this, and do it well, is going to hinge on the user following best practices when it comes to testing. I don’t think I would test an AI mediated migration without an extensive test suite.
  • It is unclear to me what your data set is required to get to the desired outcome. Is it simply enough to feed the AI the source code between two ROS distros? Would example migrations be needed? If so, what sort of projects would compose the corpus?
  • I think it is probably wise to very clear about the process required for an automated migration and the outcome. I doubt that a “click a button, your robot is now updated” outcome is possible initially. The most likely outcome is that you will need to proceed package by package and help the AI get a final compilation / tests passing. Along those lines users would probably want some visibility on what surfaces in their code base are getting touched. We probably don’t want the AI just twiddling random functions to get a tests to pass. A good migration is one with the minimum number of changes to get the job done.

Anyway, it might be helpful to propose a few potential meeting times where we can discuss further. It might be useful initially just to have people present their work on the current “state of the art.”

3

Thanks Katherine — these are really helpful points and I agree with the framing.

Platform independence is the right call. The workflow and validation layer should stay consistent, with different model providers (ChatGPT, Claude, Copilot, FOSS) pluggable underneath. The static and rule-based passes should also work without any LLM at all — the AI layers on top for the judgment-heavy cases.

On testing, fully agreed. Without solid unit, integration, and sim validation, AI-assisted upgrades are too risky for production. The tool shouldn’t mark a package migrated without a green build and tests on the target distro, and should surface coverage gaps as risk.

I see the first practical version as a package-by-package assisted workflow:

  • detect deprecated APIs and compatibility issues

  • generate targeted migration suggestions with minimum-diff bias

  • validate compilation and test integrity

  • provide clear visibility into what’s being modified and why

For the dataset, a strong starting point:

  • ROS distro API diffs and official migration guides

  • real upgrade PRs from open-source repos (Nav2, MoveIt, ros2 core all have rich histories)

  • package-level migration examples

  • deprecated interface mappings across releases

Agreed it makes sense to start with a state-of-the-art discussion. Smallest useful first deliverable in my head is a Humble → Jazzy assistant for a handful of well-tested reference packages, with Jazzy → Lyrical added once Lyrical ships in May.

Happy to organize the first meeting. Two candidate slots:

  • Tuesday, 17:00 UTC

  • Thursday, 18:00 UTC

Happy to adjust if neither works for the people we want in the room.