Core + extensions: a refactor

[adamdbrw]

I am looking to refactor the REP to Core + extensions + assets. The reasoning is as follows:

1. We won't have a complete coverage in terms of control methods or sensors: even the space is dynamic. If we don't cover these, assets won't be complete or plug and play, and vendor-specific content will fill in.
2. Each robotics control or sensor schema is a deeper subject and would be difficult to get right in this short process. Additionally, I expect a really hard path to consensus between communities.
3. glTF 2.0 and OpenUSD follow the path of Core + extensions/registries for good reasons.

My proposition is the following:

1. The REP keeps the core content and ROS interfaces and generics, as well as overarching rules for sensors and control. Examples include graceful degradation, separating ground truth in its own interface from SiL-ready data.
2. The REP announces an official schema repository, e.g. ros-infrastructure/openusd-robotics-schemas, and rules for submissions.
3. We include a few submissions for control and sensors to serve as examples, in a way that they can be discussed separately (e.g. don't block the REP acceptance).
4. Additionally, I would like to introduce ros-simulation/openusd-robotics-assets. Here, a concrete asset will be shared and can include extensions of support for specific vendors on top of standard adherence. Community can contribute support to other vendors. All submissions will be auto-checked by our compliance checker tool. All submissions need to be open-source.

[zakmat]

I do agree on reasoning and the proposed split.
Shall we propose a repository for compliance and conversion tooling as well?

[adamdbrw]

Good idea! I thought a bit about the practice - and it is best to have compliance checker and schemas in one repo - and run checker on submissions + regression. PRs need to include checker code for new schema and a mock example. This way we have a strict specification -> code pathway.

The checker will be packaged for easy use (e.g. pip install openusd-simulation-checker).

[adamdbrw]

Other ideas:

• The compliant asset repository could have payloads hosted externally (e.g. Hugging Face). These can be selectively pulled for auto-checks. It would be ideal to seed the library (one robot arm, one AMR, a sensor) - this would also field-test the standard.
• We add adoption stuff such as compliance badge for GitHub.
• Have code owners from key simulators.

[iche033]

core + extension split sounds good to me.

The REP announces an official schema repository, e.g. ros-infrastructure/openusd-robotics-schemas

Not sure if ros-infrastructure is the most fitting place for this. It could live in ros-simulation for example or another org.

Additionally, I would like to introduce ros-simulation/openusd-robotics-assets

Is this is for sharing USD assets (that any one can contribute as long as they pass the compliance checker)?

All submissions need to be open-source.

Any license considerations? CC by 4.0 and other permissive licenses?

[adamdbrw]

@iche033 it is indeed ros-simulation indeed in #23 (PR addressing this issue). I changed repo names as well.

Exactly, compliant assets shared by the community and dedicated efforts. CC 4 and similar, non restrictive licenses.