Alright. As promised. The problem persists, see the original motivation. Here’s another idea for a solution, which I believe will be idiomatic - mostly because it uses only Cyphal-Built-In services and the Plug-And-Play solution provided via PyCyphal.
The system integrator knows about the hardware built into his application. He defines a config: the future node on hardware 3 will subscribe to some topic with known type from hardware 2 with unique ID C. But at what node ID and subject ID?!
Step 0: There exists an allocator in the network, which lives in Node 1 running on hardware 1 with 128bit unique ID A. Hardware 2 with unique ID B at start only has an anonymous node which only serves as a Node-ID allocatee. It requests a node ID from the allocator with its unique ID B and gets the response: 125.
Step 1: The anonymous node in hardware 2 stops and starts a non-anonymous node with ID 125. This node now has:
- Heartbeat (mandatory)
- 430.GetInfo.1.0-Server
- Some publisher with subject ID 1234
hardware 3 runs through the same process as hardware 2, yet receives node ID 124.
Step 2:
The anonymous node on hardware 3 stops and starts node 124. Both nodes 125 and 124 are running.
Step 3:
Node 124 (see above from system integrator config) still knows it needs to subscribe to the subject of hardware 2. So it asks the allocator: who is unique-ID B and receives response node ID 125.
Step 4:
Node 124 now asks node ID 124 via GetInfo: what publishers do you have (and especially what are the subject IDs?). Gets full response including subject ID 1234.
Step 5:
Node 124 subscribes to subject ID 1234.
I have this running in PyCyphal on a virtual CAN bus. Works splendidly.
Discussion points:
- Even for identically compiled and flashed software nodes on different hardware all publishing their identical message types into subject ID 1234, the subscriber can still tell them apart by knowing the publisher’s node ID via the logic described above. So the example of left/right motor is solved.
- Network is “centralized” around the allocator, which is seemingly ok
since it’s a built-in-feature by Cyphal. Also, multiple allocators can exist in the same network. This begs the question: how are multiple allocators synchronized? - The Plug-And-Play allocator/allocatee scheme works fine in PyCyphal. For this to work in my specific case, I require anonymous nodes and an allocatee running on STM32, so libcanard. Any pointers on how to achieve this?
- Since this forum.opencyphal.org discussion the subject ID (my example 1234) can be set by the integrator via register API. The vendor will simply make them configurable with a default value.