Is IEEE 754 not supported in *.dbc files?

f.petry · April 8, 2021, 2:20pm

Please provide the following info (check/uncheck the boxes after clicking “+ Create Topic”):
Software Version
DRIVE OS Linux 5.2.0
DRIVE OS Linux 5.2.0 and DriveWorks 3.5
NVIDIA DRIVE™ Software 10.0 (Linux)
NVIDIA DRIVE™ Software 9.0 (Linux)
other DRIVE OS version
other

Target Operating System
Linux
QNX
other

Hardware Platform
NVIDIA DRIVE™ AGX Xavier DevKit (E3550)
NVIDIA DRIVE™ AGX Pegasus DevKit (E3550)
other

SDK Manager Version
1.4.1.7402
other

Host Machine Version
native Ubuntu 18.04
other

Hello,

while implementing a vehilceIO driver to communicate with a vehicle controller, I saw, that encoding a command does not result in the intended values in the CAN message.

Using this DBC file: oscc/oscc.dbc at master · PolySync/oscc · GitHub
With the following code:

status = dwCANInterpreter_encodef32(0.7f,
                                    OSCC_ID_THROTTLE_COMMAND_PEDAL_REQUEST,
                                    &msgCAN, gIntp);
checkError(result, status, "encode OSCC_ID_THROTTLE_COMMAND_PEDAL_REQUEST failed");

Results in the following message on the bus:

$candump -i vcan1,92:FF
 vcan1  092   [8]  11001100 00000101 00000001 00000000 00000000 00000000 00000000 00000000

Trying to encode the value ‘1’ has the exact same result. Using ‘100.5’ leads to:

vcan1 092 [8] 11001100 00000101 01100101 00000000 00000000 00000000 00000000 00000000

Which is ‘101’.

So it seems the value is round and then not encoded using IEEE 754, but just encoded as integer number. Is “SIG_VALTYPE_ … :1” in *.dbc files not supported?
Are there any workarounds?

Regards

VickNV · April 8, 2021, 4:58pm

Hi @f.petry ,

We will check internally and get back to you. Thanks.

f.petry · April 22, 2021, 7:50am

Hey @VickNV,

any findings yet? Unfortunately this is currently a blocker for me.

VickNV · April 22, 2021, 3:53pm

Please share the complete log including your CAN DBC parsed results (something like below). Thanks.

CAN DBC parsed results:
numMessages: 35
numSignals: 230
numSignalsExtendedValueType: 0
numIgnoredMessages: 0
numInvalidMessages: 0
numInvalidSignals: 0
numInvalidSignalsExtendedValueType: 0

f.petry · April 23, 2021, 12:18pm

[23-04-2021 13:56:07] [23-04-2021 13:56:07] DBC parser: only support unsigned signals up to 32bit
[23-04-2021 13:56:07] DBC parser: only support unsigned signals up to 32bit
[23-04-2021 13:56:07] DBC parser: only support unsigned signals up to 32bit
[23-04-2021 13:56:07] DBC parser: only support unsigned signals up to 32bit
[23-04-2021 13:56:07] DBC parser: only support unsigned signals up to 32bit
[23-04-2021 13:56:07] DBC parser: only support unsigned signals up to 32bit
DBC Parser: signal for message with ID 114 doesn't have float or unknown type at line 107:
SIG_VALTYPE_ 114 brake_command_pedal_request : 1;
DBC Parser: signal for message with ID 130 doesn't have float or unknown type at line 108:
SIG_VALTYPE_ 130 steering_command_torque_request : 1;
DBC Parser: signal for message with ID 146 doesn't have float or unknown type at line 109:
SIG_VALTYPE_ 146 throttle_command_pedal_request : 1;
CAN DBC parsed results:
numMessages: 13
numSignals: 40
numSignalsExtendedValueType: 3
numIgnoredMessages: 0
numInvalidMessages: 0
numInvalidSignals: 0
numInvalidSignalsExtendedValueType: 3

I see… there are three values invalid…

From the *.dbc file:

BO_ 114 BRAKE_COMMAND: 8 BRAKE
 SG_ brake_command_pedal_request : 16|32@1- (1,0) [0|1] "" BRAKE

BO_ 130 STEERING_COMMAND: 8 STEERING
 SG_ steering_command_torque_request : 16|32@1- (1,0) [-1|1] "" STEERING

BO_ 146 THROTTLE_COMMAND: 8 THROTTLE
 SG_ throttle_command_pedal_request : 16|32@1- (1,0) [0|1] "" THROTTLE

SIG_VALTYPE_ 114 brake_command_pedal_request : 1;
SIG_VALTYPE_ 130 steering_command_torque_request : 1;
SIG_VALTYPE_ 146 throttle_command_pedal_request : 1;

But… the signals are 32 bits long?!

f.petry · April 23, 2021, 2:22pm

Ok, the 32 bit warnings seem to be from other signals.

The ‘doesn’t have float or unknown type’ warnings disappear if I change the factor of the signal to i.e.

SG_ throttle_command_pedal_request : 16|32@1- (0.1,0) [0|1] "" THROTTLE

But the value is still not encoded to a IEEE 754 float. Encoding 0.07 looks like this in candump:

00000001 00000000 00000000 00000000

VickNV · April 23, 2021, 2:34pm

What’s the current CAN DBC parsing log?

f.petry · April 23, 2021, 3:02pm

[23-04-2021 16:52:41] [23-04-2021 16:52:41] DBC parser: only support unsigned signals up to 32bit
[23-04-2021 16:52:41] DBC parser: only support unsigned signals up to 32bit
[23-04-2021 16:52:41] DBC parser: only support unsigned signals up to 32bit
[23-04-2021 16:52:41] DBC parser: only support unsigned signals up to 32bit
[23-04-2021 16:52:41] DBC parser: only support unsigned signals up to 32bit
[23-04-2021 16:52:41] DBC parser: only support unsigned signals up to 32bit

CAN DBC parsed results:
numMessages: 13
numSignals: 40
numSignalsExtendedValueType: 3
numIgnoredMessages: 0
numInvalidMessages: 0
numInvalidSignals: 0

corresponds to:

SG_ throttle_command_pedal_request : 16|32@1- (0.1,0) [0|1] "" THROTTLE
[...]
SIG_VALTYPE_ 146 throttle_command_pedal_request : 1;

The DBC parser recognizes the extended value type only, when the SIG_VALTYPE_ line is there AND there is a fractional factor that I don’t want.

With my 0.07 example, this results in just

00000001 00000000 00000000 00000000

VickNV · April 23, 2021, 6:38pm

Is numInvalidSignalsExtendedValueType still 3?

f.petry · April 26, 2021, 6:09am

No. Sorry, the last line of the output was missing:

[26-04-2021 08:08:51] [26-04-2021 08:08:51] DBC parser: only support unsigned signals up to 32bit
[26-04-2021 08:08:51] DBC parser: only support unsigned signals up to 32bit
[26-04-2021 08:08:51] DBC parser: only support unsigned signals up to 32bit
[26-04-2021 08:08:51] DBC parser: only support unsigned signals up to 32bit
[26-04-2021 08:08:51] DBC parser: only support unsigned signals up to 32bit
[26-04-2021 08:08:51] DBC parser: only support unsigned signals up to 32bit

CAN DBC parsed results:
numMessages: 13
numSignals: 40
numSignalsExtendedValueType: 3
numIgnoredMessages: 0
numInvalidMessages: 0
numInvalidSignals: 0
numInvalidSignalsExtendedValueType: 0

f.petry · April 28, 2021, 10:40am

With this code:

    float32_t fixedValue = 0.07f;
    status = dwCANInterpreter_encodef32(fixedValue,
                                        OSCC_ID_THROTTLE_COMMAND_PEDAL_REQUEST,
                                        &msgCAN, gIntp);
    checkError(result, status, "encode OSCC_ID_THROTTLE_COMMAND_PEDAL_REQUEST failed");

and these message definitions:

BO_ 114 BRAKE_COMMAND: 8 BRAKE
 SG_ brake_command_pedal_request : 16|32@1- (0.1,0) [0|1] "" BRAKE

BO_ 130 STEERING_COMMAND: 8 STEERING
 SG_ steering_command_torque_request : 16|32@1- (0.1,0) [-1|1] "" STEERING

BO_ 146 THROTTLE_COMMAND: 8 THROTTLE
 SG_ throttle_command_pedal_request : 16|32@1- (0.1,0) [0|1] "" THROTTLE

SIG_VALTYPE_ 114 brake_command_pedal_request : 1;
SIG_VALTYPE_ 130 steering_command_torque_request : 1;
SIG_VALTYPE_ 146 throttle_command_pedal_request : 1;

The output of the DBCParser is:

[28-04-2021 12:30:33] DBC parser: only support unsigned signals up to 32bit
[28-04-2021 12:30:33] DBC parser: only support unsigned signals up to 32bit
[28-04-2021 12:30:33] DBC parser: only support unsigned signals up to 32bit
[28-04-2021 12:30:33] DBC parser: only support unsigned signals up to 32bit
[28-04-2021 12:30:33] DBC parser: only support unsigned signals up to 32bit
[28-04-2021 12:30:33] DBC parser: only support unsigned signals up to 32bit

CAN DBC parsed results:
numMessages: 13
numSignals: 40
numSignalsExtendedValueType: 3
numIgnoredMessages: 0
numInvalidMessages: 0
numInvalidSignals: 0
numInvalidSignalsExtendedValueType: 0

Even though the messages are now recognized as “ExtendedValueType”, there are two problems:

1. The messages are only recognized with a fraction factor of i.e. 0.1, but 1 is specified by the device
2. The signals are not actually encoded to IEEE float, instead the encoded message is:

vcan1  092   [8]  11001100 00000101 00000001 00000000 00000000 00000000 00000000 00000000

it should look like this (0.07 encoded as IEEE float in third to sixth bytes):

vcan1  092   [8]  11001100 00000101 00101001 01011100 10001111 00111101 00000000 00000000

So @VickNV: Either I am still doing something wrong, or there is a problem in the encoder which I cannot investigate. Could you please check this internally?

VickNV · April 28, 2021, 1:26pm

I already discussed this with our team. We will check this and update you. Thanks.

VickNV · July 20, 2021, 4:44pm

This was fixed and will be available in the next DriveWorks. Thanks.