dronecan / libcanard Goto Github PK

I am working on programming blackpill_f401cc (WeAct) as a daughter board for Pixhawk. I was using mcp2515 for can interface and Zephyr as the RTOS. How do I go about implementing libcanard there?

Hello,
im trying to decode raw throttle commands without using libcanard. The specification shows a clear way how multiple values, in this case 14bit are meant to be packed into the message. https://dronecan.github.io/Specification/figures/bit_encoding.png
However after some review of the actual traffic, there seems to be significant deviation. Only the first throttle value in a 4 channel single frame configuration is placed in compliance, to some extenend. The others are also packed, although needs shifting to fit together, in 14bit packages but have to be descattered by shifting bit pairs in an arbitrary pattern within said 14bit packets to retrieve the correct value.
Can anyone shine some light into the issue and whats the magic behind this weird encoding pattern.
Kind Regards Tobi

buffer size is incorrect on this line:
https://github.com/dronecan/libcanard/blob/master/examples/ESCNode/esc_node.c#L510

uint8_t buffer[UAVCAN_PROTOCOL_GETNODEINFO_RESPONSE_MAX_SIZE]; // this should be NODESTATUS_MAX_SIZE (which is 7 instead of 377)

When building the test this static assert fails:

/home/pi/libcanard/tests/test_scalar_encoding.cpp: In function ‘void ____C_A_T_C_H____T_E_S_T____4()’:
/home/pi/libcanard/tests/test_scalar_encoding.cpp:129:58: error: static assertion failed: Assumption is not met, are we on a 32-bit x86 machine?
  129 |     static_assert(CANARD_MULTIFRAME_RX_PAYLOAD_HEAD_SIZE == 6, "Assumption is not met, are we on a 32-bit x86 machine?");
make[2]: *** [CMakeFiles/run_tests.dir/build.make:173: CMakeFiles/run_tests.dir/test_scalar_encoding.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:124: CMakeFiles/run_tests.dir/all] Error 2
make: *** [Makefile:103: all] Error 2

gcc version:
gcc (Raspbian 10.2.1-6+rpi1) 10.2.1 20210110

I had to remove -m32 -Werror option from CMakeLists.txt to get compilation to work.

There is a warnig in libcanard.c, not sure if it's related.

/home/pi/libcanard/canard.c:1042:66: warning: conversion from ‘int’ to ‘uint8_t’ {aka ‘unsigned char’} may change value [-Wconversion]
 1042 |         payload_len = dlcToDataLength(dataLengthToDlc(payload_len+1))-1;

In the CMakeLists, it's not building because googletest directory doesn't exist.

Host OS: Ubuntu 22.04
CMake version: 3.22.1

Steps to reproduce:

1. Clone
2. cd libcanard
3. cmake -S . -B build

I'd recommend using something along the lines of these:
https://cmake.org/cmake/help/latest/module/FindGTest.html
https://cmake.org/cmake/help/latest/module/GoogleTest.html

We are having to make workaround for this here:
ArduPilot/ardupilot#23574

Based on the design goals of the library, it says it's supposed to be portable. Considering many developers develop on Ubuntu 22.04, and cmake is the most common build system, it seems like this should be enforced to work in CI rather than making calls directly to g++ IMHO.

I was trying to build bootloader for experimental AP_Periph board, but build was failing.

Traceback (most recent call last):
  File "/vagrant/modules/DroneCAN/libcanard/dsdl_compiler/libcanard_dsdlc", line 63, in <module>
    from libcanard_dsdl_compiler import run as dsdlc_run
  File "/vagrant/modules/DroneCAN/libcanard/dsdl_compiler/libcanard_dsdl_compiler/__init__.py", line 21, in <module>
    from uavcan import dsdl
ModuleNotFoundError: No module named 'uavcan' 

Appling this fix hepled:
OpenCyphal-Garage/libcyphal#318

I think that this repo should mirror this branch:
https://github.com/UAVCAN/libuavcan/tree/legacy-v0
or at least sync with it

empy version 3.3.4 works fine, empy 4.0 show:
Caught exception! 'dict' object has no attribute 'unknownScriptName'

I think it's necessary Cherry pick this commits from uavcan repo OpenCyphal/libcanard#190

Some of the cpp headers (callbacks.h cxx_wrappers.h) don't have #pragma once at the top, so they can easily get multiply included.

If I get time, I'll create a pull request for this later, but its the kind of minor annoyance that should be easy to fix.

error: size of array ‘altStackMem’ is not an integral constant-expression

 6631 |     char FatalConditionHandler::altStackMem[SIGSTKSZ] = {};
      |                                             ^~~~~~~~
make[2]: *** [CMakeFiles/run_tests.dir/build.make:76: CMakeFiles/run_tests.dir/catch/test_main.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:85: CMakeFiles/run_tests.dir/all] Error 2
make: *** [Makefile:91: all] Error 2

I deleted the -werror -m32 from the CMakeLists.txt to avoid the error mentioned in #15 but now this one. Any idea on how to fix please?

I am working on programming TMS320F2800157 as a daughter board for Pixhawk.I could not find the drivers for TI under libcanard/drivers folder. Could anyone suggest me what is the best mechanism to do so? Or is there any guideline on how to create a new driver to support a new microcontroller?

I found it quite odd that among others the Servo example still uses the canardRequestOrRespond() function that is described in the canard.h file as following:

// Legacy API, try to avoid using it, as this will not be extended with new features
int16_t canardRequestOrRespond(CanardInstance* ins,             ///< Library instance
                               uint8_t destination_node_id,     ///< Node ID of the server/client
                               uint64_t data_type_signature,    ///< See above
                               uint8_t data_type_id,            ///< Refer to the specification
                               uint8_t* inout_transfer_id,      ///< Pointer to a persistent variable with transfer ID
                               uint8_t priority,                ///< Refer to definitions CANARD_TRANSFER_PRIORITY_*
                               CanardRequestResponse kind,      ///< Refer to CanardRequestResponse
                               const void* payload,             ///< Transfer payload
                               uint16_t payload_len             ///< Length of the above, in bytes

If this is legacy API, i would suggest that the examples get updated to use the new and recommended API.
I would do it myself, but i'm not deep enough into how the library is properly used.
Thanks in advance.