Node capabilities and subject-id assignment

generationmake · July 8, 2022, 12:01am

Hi.

Is there a way to identify nodes on the bus using yakut and read their capabilities?

And how can I assign subject ids using yakut?

I think I read the manual but didn’t find the answers to these questions. So could you please help?

Thanks
Bernhard

aentinger · July 8, 2022, 5:43am

The best way to go about it is probably yakut monitor and go and see which node IDs are popping up (they are kind of hard to see but they appear at the very top of the UX, i.e. take a look here, there are the node IDs 42, 1111, 1234, 2571, 3210, 3333).

Note: You need to make sure that you are operating on the right bit-rate as the nodes. (Probably a no-brainer, but caught me.)

generationmake · July 8, 2022, 6:28am

I have already found yakut monitor but as you have already written it show the device info only in the first lines. Can I get a detailed report?

Additionally it only shows the subject-IDs which send messages but not the data types connected to them. Is there a possibility to automatically connect data type to subject-IDs?

pavel.kirienko · July 8, 2022, 10:58am

Subject-IDs are simply register values, so use “yakut register”, or simply “y r” if you (like me) have no spare second to type all these letters:

y r 125 uavcan.pub.your_subject.id 8888

This is a good point, and I also thought that the Yakut monitor should display the data type information. That information is available on the network, we just need to find a decent way of displaying it, considering the limitations of the CLI-based UI. Please do share suggestions here if you have any. While there is no ready-made user-friendly solution, you should remember that Yakut is designed to be flexible and repurposable. With that in mind, you can easily craft one simple, easy-to-remember command:

y rl 125, | jq 'map_values([.[] | select(test("uavcan\\.(pub|sub|cln|srv).+\\.(id|type)"))])' | y rb

Mind the little comma, too; it matters. You can replace 125, with a list or range of nodes like 15,125,8 or 10-50. Use --help to get help.

Here’s a demo:

generationmake · July 10, 2022, 11:49am

hi.

How is this supposed to be?
Should there be a register for every function (message) of a device to set its subject-id?
do these have pre-defined names or ids?

Thanks

pavel.kirienko · July 10, 2022, 2:06pm

There shall be a register for every port (that is, subject or service) whose data type does not have a fixed port-ID. This means that there need not be a register for the heartbeat subject since its port-ID is constant. But there must be registers for your application’s subjects like servo setpoints and such. The register naming is well-documented in the Specification and also here:

github.com

OpenCyphal/public_regulated_data_types/blob/70573cb98a346f5a9aee54ce421a8a79700df2b4/uavcan/register/384.Access.1.0.dsdl#L103-L199

      
        
            #   STANDARD REGISTERS
            #
            # The following table specifies the register name patterns that are reserved by the specification for
            # common functions. These conventions are not mandatory to follow, but implementers are recommended to adhere because
            # they enable enhanced introspection capabilities and simplify device configuration and diagnostics.
            #
            #   REGISTER NAME PATTERN                               TYPE            FLAGS                   RECOMMENDED DEFAULT
            # =====================================================================================================================
            #
            #   uavcan.node.id                                      natural16[1]    mutable, persistent     65535 (unset/PnP)
            #
            # Contains the node-ID of the local node. Values above the maximum valid node-ID for the current transport
            # indicate that the node-ID is not set; if plug-and-play is supported, it will be used by the node to obtain an
            # automatic node-ID. Invalid values other than 65535 should be avoided for consistency.
            #
            # ---------------------------------------------------------------------------------------------------------------------
            #
            #   uavcan.node.description                             string          mutable, persistent     (empty)
            #
            # User/integrator-defined, human-readable description of this specific node.

This file has been truncated. show original

generationmake · July 10, 2022, 4:54pm

thanks for clearification.
I will try to implement this.

pat1 · July 18, 2022, 7:12am

Blockquote
There shall be a register for every port (that is, subject or service) whose data type does not have a fixed port-ID.

Is not clear to me which user defined service need/can have constant port-ID.
Is clear that segregation by source node-ID is, in general, incompatible with the publish-subscribe architecture but for services ? Calling a service need to specify a node-id so is correct in general to define a fixed port-ID for services in DSDL ? We have more than one node that offer the same service; the nodes can use the same fixed port-id ? So when is useful to have services without a fixed port-ID?

pavel.kirienko · July 18, 2022, 7:43am

None.

None of the user-defined data types can have a fixed port-ID (with a marginal exception, which is not worth mentioning here probably). This is explained in the Specification (chapter 2 “Basic concepts”) and the Guide. This is not DroneCAN. Forget custom fixed port-ID, it was a terrible idea, and there is a good reason why they are no longer available in Cyphal. There are countless discussions on this forum about this already; here’s one: Choosing Message and Service IDs.

Correct.

No, and for the same reason why it is not correct to use fixed port-IDs with custom message types. A node may provide multiple instances of the same service, and it is not appropriate for the data type designer to prohibit that (unless we are talking about the very basic low-level services provided by the protocol itself, but we are not talking about them right now).

Generally, one should not expect to see many custom service types since they are somewhat limited in their ability to express complex abstractions. Let me quote the Guide:

The Cyphal Guide

Observe that relying on node-IDs to differentiate the service instances or agents would be a mistake for two reasons. The first reason is that a node-ID, per the Cyphal network model, is a transport-layer property that exists primarily to facilitate the operation of the network itself rather than to enrich the application-level contracts. Relying on the node-ID to define application-level functions constitutes a leaky abstraction throughout the layers separating the application and the transport. The second reason is that such separation presumes that each service instance or agent should be implemented by a separate node, which is not an adequate assumption for a service designer to make.

An attentive reader here might notice that Cyphal-services (not “architectural services” but “services as opposed to subjects”) are inherently bound to node-IDs and as such their ability to participate in well-architected network services is limited. This is a correct observation. This design is one manifestation of Cyphal’s commitment to providing powerful abstractions at zero cost – occasionally, certain trade-offs have to be made. Many practical services will be designed based on subjects alone without relying on Cyphal-services at all.