Revision history [back]

OK, so a few points:

1. For the IMU data, how are you accounting for magnetic declination? I assume you're handling it all within the IMU driver itself.
2. You have imu0_relative turned on for your EKF instance. That's going to make your orientations relative to the first IMU measurement.
3. Don't fuse the output of one EKF into the other. Instead, in the second instance, just fuse the same inputs as you did for the first, plus the output of navsat_transform_node.

OK, so a few points:

1. For the IMU data, how are you accounting for magnetic declination? I assume you're handling it all within the IMU driver itself.
2. You have imu0_relative turned on for your EKF instance. That's going to make your orientations relative to the first IMU measurement.
3. Don't fuse the output of one EKF into the other. Instead, in the second instance, just fuse the same inputs as you did for the first, plus the output of navsat_transform_node.

header: 
  seq: 191
  stamp: 
    secs: 1487237096
    nsecs: 119077919
 frame_id: bebop/base_link
twist: 
  twist: 
    linear: 
      x: 0.132194340229
      y: -4.89818191528
      z: -0.0242414772511
    angular: 
      x: 0.0
      y: 0.0
      z: 0.0
  covariance: [0.001, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.001, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.001, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]

header: 
  seq: 192
  stamp: 
    secs: 1487237096
    nsecs: 338866472
  frame_id: bebop/base_link
orientation: 
  x: 0.0387072677682
  y: 0.0236335869622
  z: -0.685949077348
  w: 0.726234854764
orientation_covariance: [1e-07, 0.0, 0.0, 0.0, 1e-07, 0.0, 0.0, 0.0, 1e-07]
angular_velocity: 
  x: 0.0
  y: 0.0
  z: 0.0
angular_velocity_covariance: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
linear_acceleration: 
  x: 0.0
  y: 0.0
  z: 0.0
linear_acceleration_covariance: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]

OK, so a few points:

1. For the IMU data, how are you accounting for magnetic declination? I assume you're handling it all within the IMU driver itself.
2. You have imu0_relative turned on for your EKF instance. That's going to make your orientations relative to the first IMU measurement.
3. Don't fuse the output of one EKF into the other. Instead, in the second instance, just fuse the same inputs as you did for the first, plus the output of navsat_transform_node.

EDIT 1: Here's a plot of your raw GPS data in Google Earth:

According to this data, you started in the top-left of the rectangle, then flew south, then east, then north, then west, then repeated the rectangle. The general shape maps decently to the fused IMU + velocity data (without GPS):

During the initial south traversal (the left side of the first rectangle), your drone's Y velocity was negative, implying that your vehicle was flying sideways, and in the direction of its right side:

header: 
  seq: 191
  stamp: 
    secs: 1487237096
    nsecs: 119077919
 frame_id: bebop/base_link
twist: 
  twist: 
    linear: 
      x: 0.132194340229
      y: -4.89818191528
      z: -0.0242414772511
    angular: 
      x: 0.0
      y: 0.0
      z: 0.0
  covariance: [0.001, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.001, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.001, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]

However, if your vehicle was flying sideways with negative Y velocity (i.e., right) and was also flying south, that means it must have been facing east. If it was facing east, and you corrected your IMU to be REP-105-compliant, REP-103-compliant, the IMU should read approximately 0. However, during that same traversal (around the same time stamp of the above velocity message), I saved a sample IMU message:

header: 
  seq: 192
  stamp: 
    secs: 1487237096
    nsecs: 338866472
  frame_id: bebop/base_link
orientation: 
  x: 0.0387072677682
  y: 0.0236335869622
  z: -0.685949077348
  w: 0.726234854764
orientation_covariance: [1e-07, 0.0, 0.0, 0.0, 1e-07, 0.0, 0.0, 0.0, 1e-07]
angular_velocity: 
  x: 0.0
  y: 0.0
  z: 0.0
angular_velocity_covariance: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
linear_acceleration: 
  x: 0.0
  y: 0.0
  z: 0.0
linear_acceleration_covariance: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]

That heading equates to -86.684 degrees, whereas it ought to be 0.

In other words, either your body-frame velocity is wrong, or your IMU is wrong (or maybe both, I'd have to see updated data).

If you fly again, it'll help if you make note of which way the drone was flying (i.e., flying forwards/sideways, and to which direction).

Oh, and just a heads-up: your GPS data appears to be pretty severely lagged. It follows the same shape as the drone's path, but is delayed significantly.