Splitting the Autoware.AI repository and changing the organisation

[Dejan_Pangercic]

Note: I do not really understand what benefit will splitting and re-organizing of Autoware.AI repo have. Since the plan is to transform it into a sandbox in 12-18 months from now, I really do not think that we spend our resources here very wisely.

However since this topic will also be applicable for Autoware.Auto and since at Apex we have 220 packages in a monolithic repository and everybody loves it - I will provide an input.

@gbiggs

• autoware
  Root repository. Contains a README file, the .repos file for checking out/installing Autoware
  using vcs (which will be the preferred method from 1.12), and nothing else.
• core_perception
  Core packages related to understanding the world around the car.
• core_planning
  Core packages related to planning where the vehicle should go.
• core_control
  Core packages related to controlling the vehicle so that it goes where it should.
• drivers
  Hardware drivers for interacting with hardware, such as the Velodyne driver. Ideally, all
  packages in here will be candidates for eventually being pushed upstream somewhere.
• utilities
  Packages that we develop that are not core to Autoware, i.e. you do not need them to drive a
  vehicle.
• visualisation
  Packages dealing with visualising sensor data, the state of the car, etc.

You also need:

1. core_localization
2. core_decision_making
3. examples/demos/tutorials
4. thirdparty

What I suggest is to have above as subfolders inside the autoware root folder of a monolithic repo.

@sgermanserrano

• All bundled in the same machine: this would effectively be the same approach as the current repo has, i.e. AV-related nodes, handling of startup and visualisation (Rviz) are done in the same machine.
• Distributed: this option would run AV-related nodes in one machine, whereas handling of startup and visualisation is performed in a separate device(s). This second alternative would be closer to what it would be expected for an AV, where un-needed overhead is not put on the embedded device which is performing sensor processing, control, etc

@sgermanserrano I do not fully understand how are a repository structure and where you install/run Autoware nodes connected? As it is mentioned further down, you can easily create binaries for just subparts of the repo (e.g. visualization) and install it on the same or different machine than e.g. real-time nodes.

@Ian_Colwell

• Having a separate viz repo (currently suggested)
• Having a single viz package in each core repo responsible for visualizing the custom messages from that core. So you’d have the perception_viz, planning_viz, control_viz ROS packages that are updated along with any changes to the message formats. Here I assume Autoware’s custom messages will be spread out into different custom message packages for each of the 3 main categories/repos.

Do we really plan to write our own visualization code and not use e.g. rviz, xviz, rqt_plot, etc.? With that all that we would need to save are visualization config files.

@davetcoleman

• It is difficult to guarantee a separation between safety-critical and non-safety-critical code.

This is a) certainly not applicable to Autoware.AI and b) whether a package is safety-critical or not could also be asserted via a cmake macro and depending on that you can build which CI rules and checks apply to that particular package or not.

@amc-nu

As a developer, when creating a new feature for Autoware, or writing a patch. Having to wait for all the non related packages to complete, is in many instances desesperating .

@amc-nu all of your requests can be done in one repo. I claim that it is actually even easier to design and define cleaner and minimal interfaces. For testing that no intended dependencies creep over colcon build builds the packages in an isolated mode.

@dirk-thomas

• A single issue tracker makes it clear where to create / search for tickets.
• A single PR is sufficient for any kind of change.
• All packages should be consistent with each other in every single commit.
• Making a release requires only a single tag (and in case of ROS a bloom invocation).

I would also add:

1. you do not need a feature and code freeze when doing releases, these can both be one
2. single entry point for developer, all work for developers is in one place
3. much easier to co-host documentation and code in one repo and actually make checks against changed code (e.g. changed executable names, APIs, …)
4. much better traceability from feature request, design document, code, tests, PR and CI. E.g. OSRF folks have to manually link github issues with PRs and PRs with CI/CD, e.g. https://github.com/ros2/rclcpp/pull/639#issuecomment-470160609. Here I am not 100% certain if this just a gitlab feature but in gitlab in the monolithic repo this happens automatically
5. easier to extract activity report (commits, branch graph, analytics, …)
6. easier user/organization management

@dirk-thomas

• CI is probably challenging to setup if you don’t want to build everything on each pull request even if it only touches a specific subset of the repo.
• If the amount of issues / pull requests grows with the community having all in one place might be overwhelming.
• Since releases cover the whole repo (at least with bloom in its current form that is) you have to release new version of packages which actually haven’t changed in order to ship changes in other packages.

I think that all 3 above points can be addressed:

1. if you split packages as proposed above you can modules independently and then re-use artifacts from previous builds => we are doing this
2. amount of issues/PRS can be mitigated by someone like you @gbiggs
3. as @davetcoleman mentioned this is a limitation of bloom

We are more than happy to share what we developed for our internal mono repo in terms of layout and CI.

D.