Community Group Proposal: Automated ROS Upgrade Assistant

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

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.”