waist_imu providing the same message on ergocubSN000

[SimoneMic]

Hello,

I started using the waist_imu on ergocubSN000 with the actual configurations available on ergocub-torso in robots-configuration.
The yarprobotinterface starts correctly and the device is found, however the measurements from the port /ergocub/waist/inertials/measures:o are always the same and don't change (same timestamp on all messages).

Here's a sample of the message red from the console:

(((-0.0815353832170272185831 0.00584834989370508224332 0.0559648625117919809591) 1693215805.40019536018)) (((0.193882018327713012695 9.795520782470703125 0.225864961743354825119) 1693215805.40019536018)) (((-0.535433292388916015625 -1.27944731712341308594 0.61504364013671875) 1693215805.40019536018)) (((88.65899658203125 -1.17439830303192160876 -144.7054443359375) 1693215805.40019536018)) () () () () () ()
() () () () () () () () () ()
(((-0.0815353832170272185831 0.00584834989370508224332 0.0559648625117919809591) 1693215805.40019536018)) (((0.193882018327713012695 9.795520782470703125 0.225864961743354825119) 1693215805.40019536018)) (((-0.535433292388916015625 -1.27944731712341308594 0.61504364013671875) 1693215805.40019536018)) (((88.65899658203125 -1.17439830303192160876 -144.7054443359375) 1693215805.40019536018)) () () () () () ()
() () () () () () () () () ()
(((-0.0815353832170272185831 0.00584834989370508224332 0.0559648625117919809591) 1693215805.40019536018)) (((0.193882018327713012695 9.795520782470703125 0.225864961743354825119) 1693215805.40019536018)) (((-0.535433292388916015625 -1.27944731712341308594 0.61504364013671875) 1693215805.40019536018)) (((88.65899658203125 -1.17439830303192160876 -144.7054443359375) 1693215805.40019536018)) () () () () () ()
() () () () () () () () () ()
(((-0.0815353832170272185831 0.00584834989370508224332 0.0559648625117919809591) 1693215805.40019536018)) (((0.193882018327713012695 9.795520782470703125 0.225864961743354825119) 1693215805.40019536018)) (((-0.535433292388916015625 -1.27944731712341308594 0.61504364013671875) 1693215805.40019536018)) (((88.65899658203125 -1.17439830303192160876 -144.7054443359375) 1693215805.40019536018)) () () () () () ()
() () () () () () () () () ()
(((-0.0815353832170272185831 0.00584834989370508224332 0.0559648625117919809591) 1693215805.40019536018)) (((0.193882018327713012695 9.795520782470703125 0.225864961743354825119) 1693215805.40019536018)) (((-0.535433292388916015625 -1.27944731712341308594 0.61504364013671875) 1693215805.40019536018)) (((88.65899658203125 -1.17439830303192160876 -144.7054443359375) 1693215805.40019536018)) () () () () () ()
() () () () () () () () () ()
(((-0.0815353832170272185831 0.00584834989370508224332 0.0559648625117919809591) 1693215805.40019536018)) (((0.193882018327713012695 9.795520782470703125 0.225864961743354825119) 1693215805.40019536018)) (((-0.535433292388916015625 -1.27944731712341308594 0.61504364013671875) 1693215805.40019536018)) (((88.65899658203125 -1.17439830303192160876 -144.7054443359375) 1693215805.40019536018)) () () () () () ()
() () () () () () () () () ()
(((-0.0815353832170272185831 0.00584834989370508224332 0.0559648625117919809591) 1693215805.40019536018)) (((0.193882018327713012695 9.795520782470703125 0.225864961743354825119) 1693215805.40019536018)) (((-0.535433292388916015625 -1.27944731712341308594 0.61504364013671875) 1693215805.40019536018)) (((88.65899658203125 -1.17439830303192160876 -144.7054443359375) 1693215805.40019536018)) () () () () () ()
() () () () () () () () () ()

Here are the config files used:
ecub-imu.xml

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE robot PUBLIC "-//YARP//DTD yarprobotinterface 3.0//EN" "http://www.yarp.it/DTD/yarprobotinterfaceV3.0.dtd">

<robot name="ergoCubSN000" xmlns:xi="http://www.w3.org/2001/XInclude">
  <devices>
    <xi:include href="wrappers/inertials/waist-inertials_wrapper.xml" />
  </devices>
</robot>

And waist-inertials_wrapper.xml

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE devices PUBLIC "-//YARP//DTD yarprobotinterface 3.0//EN" "http://www.yarp.it/DTD/yarprobotinterfaceV3.0.dtd">

 <device xmlns:xi="http://www.w3.org/2001/XInclude" name="waist-inertial" type="multipleanalogsensorsserver">
      <param name="period">       10                  </param>
      <param name="name">  /ergocub/waist/inertials  </param>
      <param name="subdevice">  xsensmt  </param>
      <param name="serial">  /dev/ttyS0   </param>

        <action phase="startup" level="5" type="attach">
            <paramlist name="networks">
                <!-- The name of the element can be any string (we use SetOfIMUs to better express its nature).
                     Its value must match the device name in the corresponding body_part-jx_y-inertials.xml file
                     or in body_part-ebX-inertials.xml -->
                <elem name="SetOfIMUs"> waist-inertial </elem>
            </paramlist>
        </action>

        <action phase="shutdown" level="5" type="detach" />
    </device> 

cc. @randaz81 @Nicogene

[lrapetti]

cc @GiulioRomualdi @G-Cervettini

[SimoneMic]

cc @isorrentino

[martinaxgloria]

Today I started investigating the problem related to the xsens on ergocub waist. In particular, I tried to reproduce the error with the cable and the xsens on bench and trying to read from the port (yarp read ... /ergocub/waist/inertials/measures:o), the timestamp and the measures don't change as well.

After that, in order to exclude that the problem could be the hardware, I downloaded the MT Software Suite: here, I plugged in the xsens to the ergocub-torso on bench using the USB cable @GiulioRomualdi gave me (the one that was used at the beginning to test the imu on ergocub by attaching it to the laptop) and I tried to read data from there with success:

xsens.webm

To double-check, I tried to launch the yarprobotinterface with the same configuration file used by @SimoneMic (I only changed the serial port from /dev/ttyS0 to /dev/ttyUSB0) and I tried to read the values from the port, but it was always stuck.

So, probably there's something wrong with how the measures from the imu are read and printed out by yarp or in the xsensmt device. I will check

cc @SimoneMic @isorrentino @Nicogene @pattacini

[GiulioRomualdi]

Hi @martinaxgloria , by any chance, have you tried to run the device with the config file written in https://github.com/robotology/yarp-device-xsensmt#via-multipleanalogsensorsserver

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE robot PUBLIC "-//YARP//DTD yarprobotinterface 3.0//EN" "http://www.yarp.it/DTD/yarprobotinterfaceV3.0.dtd">
<robot name="realsense" build=0 portprefix="/xsens_imu">

  <device type="xsensmt" name="xsens_imu">
    <param name="xsensmt_period">0.01</param>
    <param name="xsensmt_euler_period">0.005</param>
    <param name="xsensmt_gyro_period">0.005</param>
    <param name="xsensmt_acc_period">0.005</param>
    <param name="xsensmt_mag_period">0.01</param>
  </device>

  <device type="multipleanalogsensorsserver" name="xsens_imu_wrapper">
    <param name="period">5</param>
    <param name="name">/xsens_imu</param>

    <action phase="startup" level="5" type="attach">
      <paramlist name="networks">
        <elem name="imu">xsens_imu</elem>
      </paramlist>
    </action>
    <action phase="shutdown" level="5" type="detach"/>
  </device>

</robot>

The only difference is how the xsensmt device is launched. In this case, we do not use sub-device

[martinaxgloria]

Hi @GiulioRomualdi,

today @Nicogene and I succeeded in reading from the waist imu yarp port:

I'm going to open a PR with the changes that fix the problem

[GiulioRomualdi]

That's great! Thank you!!

[pattacini]

Super, @martinaxgloria
Remember to target robots-configuration@master as it's a fix.

[martinaxgloria]

Remember to target robots-configuration@master as it's a fix.

Hi @pattacini,
Those files are on robots-configuration@devel, not on master

[pattacini]

Remember to target robots-configuration@master as it's a fix.

Hi @pattacini, Those files are on robots-configuration@devel, not on master

This means that we introduced them only lately.
Ok then 👍🏻

[martinaxgloria]

Here the PR:

• Fix waist_imu conf files robotology/robots-configuration#558

cc @SimoneMic @isorrentino @GiulioRomualdi

[randaz81]

Mmmh here there is something unclear to me.

1. Who is the parser of the following parameters:

    <param name="xsensmt_period">0.01</param>
    <param name="xsensmt_euler_period">0.005</param>
    <param name="xsensmt_gyro_period">0.005</param>
    <param name="xsensmt_acc_period">0.005</param>
    <param name="xsensmt_mag_period">0.01</param>

I initially thought that this was the issue, a wrong default value of these periodic threads. But then I was not able to find any reference to them in the code.

2. In the end what was the reason for the issue? It is important to clearly identify the cause, to improve our knowledge of the system and avoid future mistakes. I cannot find any logical issue in using the subdevice parameter, and it seems strange to me that this is the cause( see point 3) Anyway, It is in my future plans to remove it completely from the multipleanalogsensorsserver (and other nws devices)

3. It looks like that the thread executed at least once, because some values are sent, and then repeated forever. So the attach operation was completed successfully. So the problem should not be the subdevice parameter. I'm still a little puzzled by the proposed fix 'cause I cannot find the logical connection with the reported issue...

[Nicogene]

Who is the parser of the following parameters:

See https://github.com/search?q=repo%3Arobotology%2Fyarp-device-xsensmt%20xsensmt_period&type=code

In the end what was the reason for the issue? It is important to clearly identify the cause, to improve our knowledge of the system and avoid future mistakes. I cannot find any logical issue in using the subdevice parameter, and it seems strange to me that this is the cause( see point 3) Anyway, It is in my future plans to remove it completely from the multipleanalogsensorsserver (and other nws devices)

The first issue we discovered was that the nws was attaching on itself. see:

Moreover, there was both the attach and the subdevice, I don't know what happens if you do both, it surprised that yarprobotinterface was not throwing an error because it seems to me a wrong configuration.

Removing the subdevice option and attacching the correct device fixed the issue.

[randaz81]

Who is the parser of the following parameters:

See https://github.com/search?q=repo%3Arobotology%2Fyarp-device-xsensmt%20xsensmt_period&type=code

Haaaaaa I was looking at another device: https://github.com/robotology/icub-main/tree/master/src/libraries/icubmod/xsensmtx
Is it still in use? Maybe this device is deprecated and can be removed to avoid confusion? The name differs only for the ending x.

Moreover, there was both the attach and the subdevice, I don't know what happens if you do both, it surprised that yarprobotinterface was not throwing an error because it seems to me a wrong configuration.
Removing the subdevice option and attacching the correct device fixed the issue.

I do not know either! Good catch, I did not notice that!

[Nicogene]

Maybe this device is deprecated and can be removed to avoid confusion? The name differs only for the ending x.

From what I recall the one w/ the x was the one used in the iCubGenova01 head (see https://github.com/robotology/robots-configuration/blob/master/robots-icebox/iCubGenova01/hardware/inertials/head-inertial.xml) I am not aware if it is used by other robots.

In general, seems to be used by old robots: https://github.com/search?q=repo%3Arobotology%2Frobots-configuration%20xsensmtx&type=code

Maybe @traversaro or @GiulioRomualdi can give more info on the difference between the two.

In any case this problem has been fixed. Closing

[pattacini]

In general, seems to be used by old robots: https://github.com/search?q=repo%3Arobotology%2Frobots-configuration%20xsensmtx&type=code

There are still robots that we maintain that are equipped with this device. Examples:

• iCubNancy01
• iCubHertfordshire01
• iCubTokyo01
• iCubGenova03
• iCubGenova06

So, we ought to keep the device.