Custom Plugin, retaining information in-between power cycles

Please provide the following info:
Hardware Platform: DriveWorks AGX Xavier
Software Version: Drive Software 2.2
Host Machine Version: Ubuntu 18.04.4 LTS (Bionic Beaver)
SDK Manager Version:

Note: I am running everything I mentioned below in Linux 18.4 Host machine.

Long story short, my Plugin parses data packets based on CAN IDs. If user changes one of the CAN IDs through the Plugin parameters my Plugin and IMU both adapt to that new CAN ID and keep parsing the data. Challenge is when the plugin is restarted. Plugin resets its IDs to default because it can’t store that information. And IMU still sends out last changed IDs. So my Plugin won’t be able to understand those messages unless there is a way to store this information.

Long description:
I am implementing a custom IMU plugin for our CAN based IMU product. It reads plugin parameters for IMU configuration requests from the plugin user. When _dwSensorPlugin_start() is called, my plugin sends CAN configuration messages to the IMU. In _dwSensorIMUPlugin_parseDataBuffer, uses dwCANMessage.ID to determine packet type and subsequently parse it to provide data to SAL. All the supported IDs for the product are predefined in the plugin implementation.

One of the feature we have is an ability to change PS number of the messages. PS number is part of 29-bit CAN identification data (dwCANMessage.ID). Our IMU provides an ability to change and store this PS number for any message, which essentially changes the ID of the message sent by the IMU. This is useful for the customers who has overlapping ID list and can change IMU message ID to avoid conflicting IDs.

But if this ID is changed the Plugin will no longer recognize that packet because my plugin only looks for the IDs initialized at the beginning. I can update the message ID in my plugin when user sends parameter to change the ID. But this new ID is not stored permanently by the Plugin. When User re-runs the plugin, ID list in plugin resets to the default again and looses new IDs. IMU will still be sending messages with new IDs but Plugin won’t be able to understand those messages with new IDs. To solve this problem, User is going to have to manually change the ID to default in the IMU and then use Plugin parameter to change it back to the new one so that plugin can understand the message with new ID.

Is there a better way to do this? Can I store these ID values somewhere and get my plugin to read IDs from there every time it starts and make change to those IDs every time a plugin user changes one. Can I create a .xml or text file from which my plugin reads initial id values and dump last known ID values for the use in next initialization?

I hope this makes sense. I am happy to answer any questions you might have. Or maybe you can redirect me to some threads that talks about this. I couldn’t find any.

Thank you for your time in advance.


Hi @rborad,

In any case, it seems that if the plugin was re-run, it should be transparent to the customer.

As I see it, This can be approached in 3 ways:

  1. if after changing a PS number the IMU stores the new number permanently:
  • The problem you are describing is also relevant also when the IMU will now be connected for example to another device that will not know in any case the reconfiguration that was done previously (there other similar cases too).
  • in that case, I would suggest that the best way to handle it is at the initialization phase of the plugin to reconfigure the IMU to the predefined default PS numbers. that way when the user re-runs the plugin the messages from the IMU will still be received. then again if the user decides to change a certain id to avoid conflict he will be able to still do that.
  • alternatively, if this takes too long as an initialization phase, you can prevent this feature from the user and avoid this problem.
  1. if after changing a PS number the IMU does not stores the new number permanently, and after a restart, the default values are being used
  • every time the IMU resets, you should reset the plugin PS numbers, even if the updated ones are permanently saved somewhere.
  • you might want to check the ability to reset the IMU from your plugin to achieve the usage of default IDs.
  1. if you do still want to save the updated PS numbers that were sent to the IMU to be changed you can save a json configuration file in the filesystem (like the rig files being used by DW) or another format you’d like and load them on initialization, and dumps the last known ID values. but please consider that writing to the filesystem on the fly in real-time while receiving and processing data is not something recommended in realtime applications.
1 Like

Thank you for taking time to lay out all the options here. Really appreciate it.

Based on what you said I have this idea.
One of the configuration parameter is to save the configuration permanently. I would disable this parameter for customers. So every time the IMU resets it is set to default and so does the plugin. That means every time user wants to use the IMU Plugin with new PS number he would send parameters to change the PS number. Then my plugin would update its PS number to this new PS number. I will also reset the IMU every time the plugin starts to make sure IMU is running on default configuration at Plugin initialization. I am going to have to wait for couple seconds in _dwSensorPlugin_start() or _dwSensorPlugin_reset() for IMU to restart. Is that alright timing wise for a plugin? what can I use to sleep()?

Thanks for your help.

Hello @rborad,
that seems to be a good solution.

there is no limit for the time of initialization of plugin, the initialization phase in real-time applications is more relax.

you can use:
#include <unistd.h>
unsigned int sleep( unsigned int *seconds* );
but to make the wait time precise, I’d recommend sleeping for a small amount of time and querying the IMU for readiness.

1 Like

Thank you for suggestion. I am sending restart IMU message from my startSensor(). My plugin seems to be parsing Data packets even after restarting the IMU. (IMU doesn’t send any data after a restart, i also verified this using candump). The plugin shouldn’t be parsing any data because it shouldn’t have any data to parse. It looks like my plugin receives data packet accumulated by CAN plugin before restarting the IMU. I think when I start restart the plugin I should also flush CAN packets from the CAN plugin. But I don’t think CAN plugin allows me to flush packets. Is something else is going on here?

Also, if the data is accumulating in CAN plugin does that mean CAN/IMU plugin is slower than IMU’s data sending capability? My IMU sends data packet at 200Hz.

Thanks in advance.


Hello @rborad,
It is possible that there are some can messages there were received before you restarted the IMU and are waiting in the mailbox memory.
it does not mean essentially that the IMU/CAN plugin is slower then the IMU’s data being received.

please try reading and ignoring residual messages until you get a return code from readMessage that is not DW_SUCCESS to clear the pipe.

Hello @rborad,

can this topic be closed? do you need further support?


I still have this problem. But only when I restart the IMU in plugin. I tried few things and determine that CAN plugin doesnt receive any messages after IMU restart. I also tried reading and ignoring residual messages until I got return code that isn’t DW_SUCCESS with a delay of 2 seconds. IMU Plugin discards one or two residual messages some times and moves on. My plugin still retrieves data from the ByteQueue, don’t know how it gets there at first place. Dint get chance to look more into this.

But you can close this. I will open a new topic if needed.

Thanks for your help.

1 Like