Guidelines on how to architect ROS-based systems

Hey @Allan_Scherger, welcome to the comunity!

I’d say yes, for all Working Groups (WG).

It’s up to @Alami and other folks to answer formally but in my past experience with the QA WG, I joined without notice and started participating in the meetings.

All of the working groups are open. Anyone can join at any time.

Yes, the ROS Quality meeting is open for all the ROS Community. Any community member can join listen and participate in the discussion if he/she wishes to.

1 Like

Hi all,
I am bring to life this thread since yesterday we published an extended version of our architecting guidelines, it is available here.

There we discuss in details ALL 47 architecting guidelines and include several examples about how to apply them in concrete projects. I hope that this is useful for you, people!

As usual, the raw dataset is available on GitHub as well: https://github.com/S2-group/jss-2021-replication-package

@wasowski, I see that you last edited the Quality/tutorials page on the ROS wiki, do you think it makes sense to list our guidelines there?

Ivano

5 Likes

Thnx for those guidelines. Nice to have the things I knew intuitively spelled out clearly.

I did spot one very minor error though:

ED is developed by TU Delft

That should be TU Eindhoven. Both in the Netherlands, we’re a small country, but still :slight_smile:

1 Like

Ooops, thanks @Loy for the correction.

Thanks @Loy for appreciating our work!

Ivano

1 Like

that surprised me as well, especially because in the sentence following that statement the authors include a link to the repository, which is on the tue-robotics organisation.


More interesting to me though is the fact that N8 recommends to use a single node for environment representation, gives a few examples why that would be advantageous (single source of truth mostly), but seems to ignore the fact all of those (ultimately) rely on TF – which is an asynchronous, distributed graph based approach for keeping track of coordinate frames in 6D space.

It’s very much possible for TF consumers to have a partial view of the transform tree, and thus by extension of “the world” I believe.

Wouldn’t it be more prudent to assume all world representations are always partial, and not consider any of them as an absolute source of truth?

1 Like

I wouldn’t say that this applies for all projects, it really depends on the system being developed and the used packages.