Splitting the Autoware.AI repository and changing the organisation

[gbiggs]

@sgermanserrano

Agreed with the above, what I tried to highlight is that we would need a way to compile/install just the messages in the visualising machine as opposed to having to build the whole Autoware stack for the sole purpose of handling/visualising the embedded device where the actual nodes would be running.

OK, I see what you’re after now.

It will be possible to build just the messages, because they’ll be in a separate package. So the question becomes, are we happy checking out all the core repositories just to get the messages?

@Ian_Colwell

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.

I think this suggestion is worth considering. If we put messages in the core repositories, then having visualisation packages in there as well does make sense in some ways. On the other hand, having a separate visualisation repository makes it clear that visualisation is of the messages, not the functionality. This might make it easier to work with 3rd party visualisation projects such as Uber’s xviz in the future.

Similarly having messages in a separate repository makes the separation between interface and implementation clear.

I personally am leaning in the direction of having a separate repository for messages, but I can see the argument against adding another repository.