raccoonlabdev / docs Goto Github PK

https://docs.raccoonlab.co/guide/intro/firmware_upload.html#step-1-download-firmware section should be separated by OS and programmer

My sudgestion is to make 4 separate instructions:

• Windows + Zubax Dronecode probe
• Windows + RaccoonLab sniffer
• Ubuntu + Zubax Dronecode probe
• Ubuntu + RaccoonLab sniffer

Here https://raccoonlabdev.github.io/docs/guide/#introduction
its better to write

Cyphal / DroneCAN (old name UAVCAN)

instead of

DroneCAN (opens new window)/Cyphal (opens new window)(old name UAVCAN)

I am trying to capture packets using yakut.

We have connected a UAVCAN mux v5 to our CAN connector and attached one GNSS and PWM NODE v2.

When we run innopolis_vtol_dynamics/scripts/docker.sh, we can see that it creates an slcan, as confirmed. We referred to OpenCyphal/yakut and only modified the port serial to fit our environment.

When we run yakut mon, the following window appears twice and quickly disappears,

then changes to the following window.

The PX4_FMU_V5 is recognized, but the GNSS MAC BARO and PWM NODE v2 node items do not appear. I am not sure what co.racoonlab.communicator means. Despite trying various hardware approaches and modifying the environment variables according to OpenCyphal/yakut, we could not find the nodes. We think that registering the node or uploading firmware to the node might be necessary, but there is a lack of explanation for this part. We are unsure which file needs to be uploaded to the PWM NODE v2.

Could you advise on any additional settings or help related to node or node registration?

Release package v1.4 for Cyphal has a compiled binary for the Micro, but not the Mini v2. When flashing the Mini with this firmware, it works, but I can only control PWM1, not PWM2-4. I fixed this by reverting back to the v1.2 release of Cyphal (separate binary for Mini v2), which gave me control over all PWM channels.
I think the only issue is that the firmware update guide links to v1.4 for both the Mini & Micro. I think that either the v1.4 FW should be recompiled to include a Mini binary too, or update that webpage to link to the v1.2 release for the Mini specifically.

The UAVCAN node documentation uses the term "service consumer" incorrectly to describe what are in fact UAVCAN RPC-services. This applies both to the English and Russian docs.

The term "service consumer" is used in UAVCAN in the same sense as it is used in service-oriented architectures: a service consumer is a component of the distributed system whose operation is facilitated by another component via a well-defined contract. That latter component is commonly called a "service provider".

It is important to understand that while the terms "RPC-service" and "network service" sound similar, they describe entirely different entities:

• An RPC-service is what you define using the three-dash DSDL notation ---, or like .srv files in ROS. For example, uavcan.node.GetInfo defines an RPC-service.

• A network service is a well-segregated functionality accessible via the network that upholds a certain behavioral contract. For example, this is the definition of the UDRAL ESC service: https://nunaweb.uavcan.org/api/storage/docs/fgsfds/reg/index.html#reg_udral_service_actuator_esc

To quote the Guide:

A given component of a distributed UAVCAN-based computing system is said to provide service if it participates in the data exchange using a specific well-defined set of UAVCAN data types following the formal requirements imposed by their definitions. Usually, this involves publishing messages of well-defined types carrying particular data at specific rates. Also, it may involve responding to UAVCAN service requests as dictated by their data type definitions.

Similarly, a given component is said to consume service if it relies upon the formal contractual obligations upheld by a service provider as defined above. Usually, that involves subscribing to messages of a specific type or making calls (sending requests) to a specific UAVCAN service.

There is an unfortunate linguistic complication in the fact that a service can mean both the type of UAVCAN communication (as opposed to messages) and a higher-level architectural entity. In this piece, we’re mostly focused on the latter.

https://docs.raccoonlab.co/guide/programmer_sniffer/hardware.html

Hello Team,

I am currently using the Cyphal CAN sniffer from Racoonlabs and need guidance on setting it up in a Windows environment. I would appreciate it if you could provide assistance in configuring the CAN sniffer.