Is there / could there be a standard robot package structure?

ROS ROS General
1

Hi all! I imagine this might be one of those recurring noob questions that keep popping up every few months, please excuse my naivity..

I am currently working on a ROS 2 mobile robot (diff drive, with a main goal of easy hardware reconfigurability). Initial development took place as a tangled monolithic package, and we are now working on breaking it up into logically separate packages for: common files, simulation, physical robot implementation, navigation stack, example apps, hardware extensions, etc.

To my understanding, there is no official document that recommends a project structure for this, yet still, “established” robots (e.g. turtlebot4, UR, rosbot) seem to follow a similar convention among the lines of:

  • xyz_description – URDFs, meshes, visuals
  • xyz_bringup – Launch and configuration for “real” physical implementation
  • xyz_gazebo / _simulation – Launch and configuration for a simulated equivalent robot
  • xyz_navigation – Navigation stack
  • …

None seem to be exactly the same, though. My understanding is that this is a rough convention that the community converged to over time, and not something well defined.

My question is thus twofold:

  1. Is there a standard for splitting up a robot’s codebase into packages, which I’m unaware of?
  2. If not, would there be any value in writing up such a recommendation?

Cheers!

ROS News for the Week of February 2nd, 2026
2

Hi, there is ROS Package Naming | Robotics Enhancement Proposals .

2 Likes
3

A lot of it is really just iteration.

That’s pretty much it. As you use your stack beyond what you initially intended, you’ll realize couplings that you may want to detangle.

Sometimes community decisions grow organically and make a lot of sense, but sometimes you’ll also find legacy decisions that may not make sense for your case.

A good example for legacy decisions (on a package level) is the launch backend that somehow slipped into a lot of frontend usage.

Other examples are that many robot descriptions contain ros2_control-related xacro, which really should live in xzy_ros2_control.