Node capabilities and subject-id assignment

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

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.)

1 Like

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?

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:

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

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:

thanks for clearification.
I will try to implement this.

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?

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: