Hello Pavel. There was a problem with the correctness of the formation of the CRC for the message ardupilot.equipment.trafficmonitor.TrafficReport. I use the canard 0.2 library.
When debugging the Ardupilot CubeBlack sources, an inconsistency was found when calculating the checksum in TransferListener :: checkPayloadCrc. Temporarily disabling this CRC check on CUBE, I made the package pass further; adding the line send_adsb_vehicle (chan) at the end of the function void AP_ADSB :: handle_adsb_vehicle (const adsb_vehicle_t & vehicle) got the correct display of test adsb objects sent by the microcontroller via the uavcan .
After making sure that the data from the packets is displayed correctly, I still could not solve the problem with the correctness of the CRC (for adsb message) in the canard 0.2 version. Is it possible to solve this problem within canard 0.2 - at least as a friendly exception ?!
Based on your description, you are using libuavcan, not libcanard, so I’ve moved this conversation into the correct category.
The issues you are observing can be explained by multiple implementations using different DSDL source. Ensure that you are using exact same DSDL files everywhere, recompile DSDL, and things should start working again.
While you are at it, consider pressing your autopilot vendor to adopt UAVCAN v1, because: 1. v0 is obsolete, 2. v0 doesn’t have scalable support for vendor-specific DSDL, and 3. issues of this kind cannot occur in v1 by design.
Could you give a link that describes how to get the DataTypeSignature to calculate the resulting CRC for the uavcan frame v0.2 ?! As I understand it, the current script generates the SIGNATURE_CRC signature based on the format of the message fields and its file hierarchy, was it possible to get different CRC values depending on the location of the folder structure ?!
Is there a script that processes one specified dsdl file selectively, which stores a example record like this: