Problems regarding the SBG device configuration

[ErwanCL]

Hello all,

Based on the commit d24d23f, on the devel branch, I have introduce a configuration store, to handle the device configuration.
The idea is to separate the configuration from the Ellipse class itself. The configuration is read from the yaml file, and then updated on the connected product, as it was done before. I clean up the configuration by directly using Sbg structure, which are used to define the configuration, instead of having huge number of integer variables, casted everytime.

All of this was done to clarify the code, add the error handling and make the configuration of the product easier.
However, this brings also side effects, not really wanted.

Features in SBG devices

• Features (Odometer, GPS, Magnetometers, ...) are not defined for all products, and for all firmwares
• Some configuration functions will return SBG_TIME_OUT as the feature is not defined, the driver will so exit during the initialization (this is not the wanted result for your applications)
• SBG device should be able to know what features are available, and handle functions if the feature is not. We are aware on that, and will work on that directly in the sbgECom library, to improve it (It may take some time to achieve the changes on this library, as we want to improve all the settings part as well)

Configuration of the sbg_driver

• The easiest solution for now, instead of throwing exceptions during the initialization, just log warnings/errors for the corresponding functions (Error codes from the SbgECom should be handled and checked every time, in order to know if your operation was successfull)
• The user should be aware of the features of his device, so the configuration can be updated according to the product, but that is not really user-friendly
• A NO_CONFIGURATION mode can be added, for the user to just use the connected device without thinking about the configuration. We can suppose that the user configure the product on the sbgCenter and just want to use it on the driver. This idea seems the more natural, as when you mount a device on your platform/robot, the device should have been configure before. This mode will allow connection with other SBG devices as well (Ekinox, Apogee), because we will just need the connection and then receiving the data coming from the device.

User's cases

On this point, I will need some of your feedbacks if possible !

• If we take the previous state of the driver, configuration was read from the device and updated if it was different from the configuration. Once again, as the error codes weren't handled, I guess that some functions did never work on your devices as well, without noticing it. The question is, do you often change your configuration file ? Or as it is used for one specific application, you just configure it once ?

• Did you configure your device on the sbgCenter, or did you always configure it directly from the config file ?

Futures fixes/changes

• At first, I will remove the exception during the initialization and change it with just warnings to keep checking the errors, and avoid your applications to crash
• A mode will be added to use the device without direct configuration.

Obviously, I am opened to comments, suggestions, and contributions,

Regards,
Erwan

[ThomasLeMezo]

Did you configure your device on the sbgCenter, or did you always configure it directly from the config file ?

• As far as I know, the sbgCenter is not available on Linux, so it is not possible to configure directly the imu on the same computer as the robot (assuming that ROS is used with Linux which is mostly the case).
• Most of the time it is difficult to have a physical access to the imu and especially during trials where several configurations have to be tested, without mentioning the need to have a "Windows" computer...
• Moreover, the huge advantage of a ROS configuration is the ability to use the imu for different robots without re-configuring each time the imu through the sbgCenter.
• It is also safer to know that the device has been correctly configured when the mission starts.

So I would say that configuration through the ROS driver is an important feature ;)

[ErwanCL]

Thanks for your feedback @ThomasLeMezo :)

As far as I know, the sbgCenter is not available on Linux

This is right, but the SDK given to the client is suitable with Linux system, so you can configure a device by writing code on the SDK (Like it is done in the ROS driver in fact), so on the same computer as the robot. But I agree, this is not user-friendly, and you will have to write code in different places, so no real interest there.

So I would say that configuration through the ROS driver is an important feature ;)

You are right about this for the different points you said.

It is also safer to know that the device has been correctly configured when the mission starts.

Actually this wasn't done before, no checks were done on the configuration, you couldn't be sure your device was well configured. That is why I added error handling, but without blocking the configuration due to the different type of devices.

When you start a mission on your robot, if the configuration of the product failed, you won't start the test anyway, so in fact, you have to configure well your device before, by the sbgCenter or by the ROS driver.
My point is that having a ROS node which does the configuration and the data receiver doesn't seem appropriate, as if the configuration failed you won't do anything, and maybe if you configure your device before (like in the webpage for Ekinox and Apogee), you don't want ROS to configure again your product, as it won't be possible anyway.

That is the reason why I think we should define a specific node just for configure your product (as for the magnetic calibration), which will check every commands you want to set and give informations about it. So once it is done, your product will be well configured for your application, as you will have to check, before launching the test.
This allows the same behavior as now, by configuring your product first, and then by launching the test node.
Furthermore, if you don't want to configure your product from ROS, because it was done before (sbgCenter or webpage for instance), you will be able to use it directly.

These changes will also make the integration of the other devices very easy !
In fact, all of them are the same, we can just send configuration commands (which most of them will be ignored for Ekinox/Apogee) but the user knows what are the possibilities of its device. And you can just use the receiver node to handle data coming from it.

I have tested on a Ekinox device, by two methods.
First I configure it on the webpage to set output data on the portA of the device, and with the corresponding cables, I am able to receive data from the ROS driver.
Second, I added the possibility to define an Udp interface, to have a connexion with the IP address of my product.

So I will do some changes which allows every user to

• Configure a device through a ROS node and yaml file (as it is done) with error handling, and user informations
• Read coming data from any kind of SBG device (Ellipse, Ekinox, Apogee (I will test it soon))

[ThomasLeMezo]

I'm not sure it is useful to have a specific node just for the configuration as it won't have any interaction with other node. Moreover, launching ROS just to have one configuration node working is a bit heavy. The case for the magnetic node is slightly different, as we might want to use other (ros-)part of the robot while launching the calibration process: for instant the robot propellers to make it turn.

I'm agree that a check of the configuration should be done when launching the driver to ensure that the user didn't forget to configure correctly the SBG device. The driver should also display warnings/error messages if there is an issue with configuration.

An interesting option to implement could be to let the user choose if he want the device to be configured at each launch or not.
From a user point of view, the configuration process should be as simple as possible with a limited number of steps and launch procedures. This is why I would prefer a single launch file with a centralized configuration file. We should assume that the user don't necessarily know how to code in C/C++ nor has the time to study in detail the SBG datasheet. The idea is to have a plug and play device that allow to rapidly get (standardized) data.

The magnetic calibration could be, with this point of view, integrated in the main node and not as a different procedure.

[ErwanCL]

A node for configuration could indeed sounds like an overkill solution. As you said, the easiest way will be a configuration parameter to configure or not the device.

I agree for the configuration, it should be as simple as possible. In fact, as it is now, it should stay a standard configuration, so most of the users won't have to look for specific configuration. The driver will just display warnings for features that couldn't be configured, and it will be the user's mission to check for every warnings (the user should be aware if it is not available on their devices).

Not sure about the magnetic calibration. This is a special operation, which is not directly related to a test. So when you want to calibrate your device, this is for a special purpose, so integrating it directly in the main node does not seem appropriate.

One of the reason for the specific application mode / node for configuration is that you can have some troubles for baudrate settings, let's take an example.
You have a default device at a baudrate of 115200, so in your configuration file, you will define the UART configuration with a 115200 baudrate. But in fact, you want to change the baudrate of your device to 921600, so you apply the corresponding command, and at the end, you save the settings (which will reboot the device). You have now a device on a 921600 baudrate, opened on an interface at 115200. If you're working in the same node, which configure the device and then start receiving data, you won't have anything because of these baudrates.

[ThomasLeMezo]

Concerning the baudrate, the driver could test at startup several values if the actual value does not work. It could also re-open the UART port when the baudrate is changed. For some systems such as ublox gps, the software automatically determines the baudrate which simplify the connection set-up.
It would be also interesting to know if the sbg device could avoid or limit rebooting after changing the parameters as it requires a new warm-up for bias estimation.

The magnetic calibration is started and stoped through a ros service so it can be seen as a state machine which is either in run mode or calibration mode.

[ErwanCL]

I made some changes on commit 3f1118d, to have a unified way to handle all SBG devices, and as you suggested, I added a parameter to allow (or not) the configuration of the SBG device.

This allows the driver to work for devices which can't be configured via sbgECom commands. I have tested it on a EkinoxA :

• Configured via the sbgCenter to get output data from portA, and use in uart configuration
• Directly via an udp interface defined in the sbg_device_udp_default.yaml

The configuration parameter is defined as confWithRos in the setting files. For instance with my EkinoxA (which can't be configured), I can use it without the configuration, so just receiving data configured previously, and if I set the configuration through ROS, I will receive warnings messages for all commands (which is normal for my device) and then use it normally.

[ErwanCL]

Configuration can be enabled/disabled by the user from the settings file.