What is being published on topic /vectornav/IMU?

[zdjeffri]

I reviewed the code, but saw that fill_imu_msg just references a composite data, and reading other issues did not help. My question is: is the data on /vectornav/IMU the 'raw' data or the output of the on-sensor kalman filter?

[berndpfrommer]

I believe the magic happens in the configuration of the binary output. It will determine what data the IMU will send over the serial line. It looks like it enables the COMMONGROUP_QUATERNION messages which asks for estimated messages, not the raw data.

// Configure binary output message
  BinaryOutputRegister bor(
    ASYNCMODE_PORT1,
    SensorImuRate / package_rate,  // update rate [ms]
    COMMONGROUP_QUATERNION | COMMONGROUP_YAWPITCHROLL | COMMONGROUP_ANGULARRATE |
      COMMONGROUP_POSITION | COMMONGROUP_ACCEL | COMMONGROUP_MAGPRES |
      (user_data.adjust_ros_timestamp ? COMMONGROUP_TIMESTARTUP : 0),
    TIMEGROUP_NONE | TIMEGROUP_GPSTOW | TIMEGROUP_GPSWEEK | TIMEGROUP_TIMEUTC, IMUGROUP_NONE,
    GPSGROUP_NONE,
    ATTITUDEGROUP_YPRU,  //<-- returning yaw pitch roll uncertainties
    INSGROUP_INSSTATUS | INSGROUP_POSECEF | INSGROUP_VELBODY | INSGROUP_ACCELECEF |
      INSGROUP_VELNED | INSGROUP_POSU | INSGROUP_VELU,
    GPSGROUP_NONE);

The ROS2 driver has support for both the raw and the kalman filtered data: https://github.com/dawonn/vectornav/blob/ros2/vectornav/src/vectornav.cc When it parses the composite structure for raw data it grabs the accelerationUncompensated field, for the estimated data it uses the quaternion field which is also what the ROS1 driver uses in fill_imu_msgs.

[zdjeffri]

I'm not familiar with ROS2 but it looks like both raw and filtered data (uncomp and comp) are being published in the same message, and that message lacks an orientation component similar to ROS1 sensor_msgs/Imu. Am I correct in this interpretation? Is there a specific reason orientation is left out?

If so, would it be feasible for me to add a second publisher to the ROS1 node that leverages a second binary output configuration and calls the accelerationUncompensated methods? Not sure if this is an "architectural" sticking point between the ROS1 and ROS2 drivers.

[berndpfrommer]

Your interpretation of what the ROS2 driver does looks correct to me. I believe the orientation is left out because unlike the "uncompensated" angular velocity and linear acceleration, orientation is only available via integration of the angular velocity (e.g. Kalman filtering). As such it is not raw sensor data and thus not published. As far as architectural modifications to the ROS1 driver goes that's a question to be answered by the original designers of the driver. Unless you need both the filtered and the raw data you may as well just hack the driver for your own purposes and publish the uncompensated data instead of the filtered one.