UAVCAN doesn't work on pixracer (but works on pixhawk 2.1). couldn't start parameter count: -2

Roman_s · March 31, 2020, 5:27pm

Hello all,
I am trying to connect two GNSS modules (here2) through UAVCAN bus. I have successfully done it on Pixhawk 2.1. Here’s what uavcan status nsh command gives me:

Shortly after turning on, it starts producing gps_fix messages, everything works great from the box.

I then try the same for pixracer. I try the same setup, connecting it to the only UAVCAN bus on the pixracer chip (unlike pixhawk, pixracer only has one CAN). Both here2 modules light up blue, indicating they have started correctly. However, the UAVCAN driver doesn’t see them. Here’s what uavcan status command outputs:
pixracer status

And here is the log file:

I googled this error and the only thing I’ve found is this, but it doesn’t seem relevant to my problem.

Additional info: both pixHawk and pixracer had the same stable 1.10 Frimware version. I tried connecting both one and two here2 modules to the pixracer. With one module I tried both with and without CAN HUB in between, same result. Yes, I have enabled UAVCAN in QGC; these parameters were identical for PixHawk2.1 and pixracer when I performed the tests:

identical

The error [uavcan] UAVCAN command bridge: couldn't start parameter count: -2 remains on pixracer even when there are no UAVCAN devices connected to the input (which might be an indication of a hardware problem).

Anyone has any ideas what the problem may be?
Thanks in advance!

JulianOes · April 1, 2020, 11:53am

Maybe @PavelKirienko knows this.

PavelKirienko · April 1, 2020, 12:43pm

The error code means InvalidParam:

github.com

UAVCAN/libuavcan/blob/7f811aee64e39d8ee56d3fead2d289f3b2a51f03/libuavcan/include/uavcan/error.hpp#L26


* Common error codes.
*
* Functions that return signed integers may also return inverted error codes,
* i.e. returned value should be inverted back to get the actual error code.
*
* Return code 0 (zero) means no error.
*
* @{
*/
const int16_t ErrFailure                 = 1;   ///< General failure
const int16_t ErrInvalidParam            = 2;
const int16_t ErrMemory                  = 3;
const int16_t ErrDriver                  = 4;   ///< Platform driver error
const int16_t ErrUnknownDataType         = 5;
const int16_t ErrInvalidMarshalData      = 6;
const int16_t ErrInvalidTransferListener = 7;
const int16_t ErrNotInited               = 8;
const int16_t ErrRecursiveCall           = 9;
const int16_t ErrLogic                   = 10;
const int16_t ErrPassiveMode             = 11;  ///< Operation not permitted in passive mode
const int16_t ErrTransferTooLong         = 12;  ///< Transfer of this length cannot be sent with given transfer type

Which in plain English means that something is messed up badly in the parameter bridge. At any rate, I don’t think it is related to your problem. You need to whip out your USB-to-CAN adapter and investigate what’s happening on the bus.

Roman_s · April 1, 2020, 4:08pm

Thanks. Just in case, I have traced it down the error comes from this line:

github.com

UAVCAN/libuavcan/blob/7f811aee64e39d8ee56d3fead2d289f3b2a51f03/libuavcan/src/node/uc_service_client.cpp#L42


                                     const char* dtname,
                                     NodeID server_node_id,
                                     ServiceCallID& out_call_id)
{
    /*
     * Making sure we're not going to get transport error because of invalid input data
     */
    if (!server_node_id.isUnicast() || (server_node_id == node.getNodeID()))
    {
        UAVCAN_TRACE("ServiceClient", "Invalid Server Node ID");
        return -ErrInvalidParam;
    }
    out_call_id.server_node_id = server_node_id;


    /*
     * Determining the Data Type ID
     */
    if (data_type_descriptor_ == UAVCAN_NULLPTR)
    {
        GlobalDataTypeRegistry::instance().freeze();
        data_type_descriptor_ = GlobalDataTypeRegistry::instance().find(DataTypeKindService, dtname);

specifically, the server_node_id.isUnicast() condition is false.

I’ll keep this thread updated.

Roman_s · April 6, 2020, 10:13am

It turned out to be a HERE2-related hardware problem described here:

Closing this.