Migrate to ros2dds bridge

[luca-della-vedova]

Closes #17.

This seems to work but required a fair bit of changes in the nexus_network_configuration package, so we should probably rethink what that package does and how.

Specifically, it had a builtin support for generating configs from redf, but it actually didn't and just used hardcoded endpoints here.
Furthermore, while with the dds plugin we can just specify endpoints as strings, the ros2dds plugin requires us to clearly say whether each substring is a publisher, subscriber, service server, service client, action server or action client.
The way I approached it in this PR is the same as the previous PR, updating the config file accordingly, however there are a few important changes to consider

Redf compatibility

redf does not have a way to specify for each topic / service etc. which nodes can publish and which can subscribe, so the only way to include redf config in its current implementation would be to allow each entity to be both, which breaks the isolation a bit since (for example), we currently do:

# System orchestrator
    allow:
      service_servers: [[...] "/register_workcell"]

# Workcell
    allow:
      service_clients: ["/register_workcell"]

Allowing both would mean technically allowing a rogue workcell to advertise a /register_workcell client which could create a lot of trouble in the system.
Note however that this is also an issue in the current implementation.

Because there was no usage of redf for network configuration I couldn't test it and whether it worked or not before I'm fairly sure it will stop working with this PR.

Queries timeout

The ros2dds bridge adds a concept of timeout for a query. They can be pretty granular but the main issue is that they also apply to actions so if an action was to take longer than the specified value it would fail.
I set it to 10 minutes as a default, but this should probably be double checked (increased? made more granular?).

Namespaces

Sadly, while the ros2dds bridge supports namespaces, they currently also apply them to global topics. This means that if we set a bridge with namespace workcell_1 and asked it to allow a subscription to /chatter it would silently only allow /workcell_1/chatter. This makes it pretty painful because workcells need to access global services to register, so we can't rely on namespaces and have to add them manually to each workcell configuration.

Warning spam

Last but not least, running the ros2dds bridge results in a lot of warnings being printed, they seem to be harmless but are still very noisy. An upstream issue has been opened and acknowledged by Zettascale.

[Yadunund]

Any idea if these TODOs are still valid?

[luca-della-vedova]

The demo / integration test works well but the configuration of these endpoints depends on where nodes are ran / how complete we want this config file.
The main crux is that in this specific implementation the system orchestrator and the transporter node run in the same domain ID so technically it is not necessary to allow all the transporter interfaces through Zenoh.
On the other hand, if we want to have this file be kind of a template that would also allow external transporters to connect to the system orchestrator we would need to add their interfaces here.

For the estop I'm just not 100% sure how it is supposed to work, since it seems it is a global topic do we just halt the whole system as soon as one workcell decides to estop? That sounds a bit dangerous so I left a note here.

I'm erring on the side of "make this a template" at least until a proper redf integration for generation of config files is not done and permissively allow all the interfaces we might need but what do you think?

[luca-della-vedova]

Warning spam was fixed upstream and in the bumped dependency 20c2eb6