How to resolve incomplete /imu/data fields

[Scottapotamas]

I've not seen much regarding the 'expected' output on /imu/data from the xsens_driver, I've got issues with the inbound messages containing any combination of orientation, vel and acc, with the values going to { 0 } often.

Do I need to modify the default sampling rates/try and sync them?

A plot shows the effect quite well:

header: 
  seq: 374343
  stamp: 
    secs: 1539651457
    nsecs: 343955039
  frame_id: /imu
orientation: 
  x: -0.00382859236561
  y: 0.00172457203735
  z: 0.999918520451
  w: 0.0120584191754
orientation_covariance: [0.01745, 0.0, 0.0, 0.0, 0.01745, 0.0, 0.0, 0.0, 0.15708]
angular_velocity: 
  x: 0.0
  y: 0.0
  z: 0.0
angular_velocity_covariance: [-1.0, -1.0, -1.0, -1.0, -1.0, -1.0, -1.0, -1.0, -1.0]
linear_acceleration: 
  x: -0.0229027047753
  y: 0.0022353194654
  z: 0.016420841217
linear_acceleration_covariance: [0.0004, 0.0, 0.0, 0.0, 0.0004, 0.0, 0.0, 0.0, 0.0004]
---
header: 
  seq: 374344
  stamp: 
    secs: 1539651457
    nsecs: 348462104
  frame_id: /imu
orientation: 
  x: 0.0
  y: 0.0
  z: 0.0
  w: 0.0
orientation_covariance: [-1.0, -1.0, -1.0, -1.0, -1.0, -1.0, -1.0, -1.0, -1.0]
angular_velocity: 
  x: -0.00361352227628
  y: -0.00345708127134
  z: 0.000307317939587
angular_velocity_covariance: [0.0004, 0.0, 0.0, 0.0, 0.0004, 0.0, 0.0, 0.0, 0.0004]
linear_acceleration: 
  x: -0.077241808176
  y: 0.0415544435382
  z: 9.81361865997
linear_acceleration_covariance: [0.0004, 0.0, 0.0, 0.0, 0.0004, 0.0, 0.0, 0.0, 0.0004]
---
^Cheader: 
  seq: 374345
  stamp: 
    secs: 1539651457
    nsecs: 353487014
  frame_id: /imu
orientation: 
  x: 0.0
  y: 0.0
  z: 0.0
  w: 0.0
orientation_covariance: [-1.0, -1.0, -1.0, -1.0, -1.0, -1.0, -1.0, -1.0, -1.0]
angular_velocity: 
  x: 0.0
  y: 0.0
  z: 0.0
angular_velocity_covariance: [-1.0, -1.0, -1.0, -1.0, -1.0, -1.0, -1.0, -1.0, -1.0]
linear_acceleration: 
  x: 0.0101052280515
  y: -0.0128167485818
  z: -0.00693368911743
linear_acceleration_covariance: [0.0004, 0.0, 0.0, 0.0, 0.0004, 0.0, 0.0, 0.0, 0.0004]

I'm trying to work with a MTi-300 over USB, running an Odroid XU4 (armhf), Ubuntu 16.04, Kinetic.

I launched it with the standard roslaunch xsens_driver xsens_driver.launch. Could this be an configuration issue perhaps? I've tried this with two MTi-300 units and one of them is better but still exhibits the issue.

[fcolas]

When xsens updated their communication protocol in their 4th generation, they added the capabilities to send various information channels at different frequencies and in different messages, rather than all at the same time in a single message. Often, when you ask various info at the same frequency, they will be grouped in the same message, but there is no guarantee. What the node is doing is simply take the information in a message when it arrives and fill what bits of message it can. If the information arrives at the same time (in the same message) it will be published in the same ROS message but if it arrives in different message at different times it will be published in different ROS messages. And that's probably for the best since otherwise it means messing up with timestamps and/or making unwarranted assumptions.

In your case, the info is not transmitted at the same time by the IMU and hence is not published at the same time. What you can check is that the frequencies of the different messages are the same (check with rosrun xsens_driver mtdevice.py -i) and change them accordingly. Otherwise, if you need them synchronized, you can add a node that will fuse information from successive ROS messages based on assumptions that you can make knowing your system and configuration.

In any case, these null values shouldn't be a problem and should just be ignored. Recall that the convention is that missing information is indicated via the value -1 in the first element of the covariance matrix (check the message definition and it's probably written elsewhere in the ROS documentation).

edit: as it's not a bug of the driver (if you disagree don't hesitate to let me know) I'll close it.

[Scottapotamas]

Thanks a lot, didn't know about the -1 covariance value.