Please provide the following info (check/uncheck the boxes after creating this topic):
Software Version
DRIVE OS Linux 5.2.6
DRIVE OS Linux 5.2.6 and DriveWorks 4.0
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.8.0.10363
other
Host Machine Version
[*] native Ubuntu 18.04
other
Hi everyone,
We are using DRIVE AGX Xavier platform and our application requires 4 CAN buses in order to communicate with the vehicle.
As mentioned on the documentation, only CAN 2 and 6 are directly accessed from the Xavier processors, while all remaining 4 channels are accessed from the MCU Aurix processor.
Since our system requires 4 CAN buses, we have opted to use the Aurix CAN configuration and we are in the middle of performing the first tests. During testing we noticed that the Aurix CAN buses present quite poor performance, since the period of the messages is not always steady at 10ms.
On the plot below you can see the performance of aurix can when running the default sample with command:
./sample_canbus_logger --driver=can.aurix --params=ip=10.42.0.146,bus=a,config-file=/usr/local/driveworks/data/samples/sensors/can/EasyCanConfigFile.conf --send_i_understand_implications=10 --send_id=150 --send_size=8
As you can see, from the 4000 recorded samples, the period is almost always maintained at 10ms but every now and then the period spikes to 20,30,40 and even 100 or 110 ms, which is not acceptable for a robust CAN communication.
For comparison, when running the exact same sample with same arguments, using socket CAN the performance is perfect.
./sample_canbus_logger --driver=can.socket --params=device=can0 --send_i_understand_implications=10 --send_id=150 --send_size=8
As you can see on the caption below, for 4000 samples the period is constantly maintained at 10ms with very little error at ~5%.
What is going wrong here? Is there an inherit problem with Aurix CAN interface that creates these delays and can we configure Aurix CAN in another more robust way?
Since our application requires 4 CAN buses this is a major issue for us, so please advise us on what to do.