Yaw issue on v1.11.0 Beta-2

[marcelino-pensa]

Describe the bug
First of all, I was flying in v1.10.1 using mavros 1.2.0 to feed odometry to the drone through the topic /mavros/odometry/out. I have the parameters EKF2_AID_MASK = 280 (external position + external yaw + external velocity), and EKF2_HGT_MODE = Vision. I am getting odometry using a T265 Intel Tracking camera mounted on my quadcopter.

Most of it works, as position and yaw are able to follow my inputs (I compare what I feed with /mavros/local_position/pose). But then I realized that velocity fusion was not working properly, which is probably due to the problems described in this issue.
I did two things to verify that velocity fusion didn't work:

1. Left the drone sitting on the floor without touching or arming it. The T265 velocity measurements was very close to 0m/s. Within seconds px4's velocity estimates would go to something like 0.5m/s in the z direction.
2. I faked a sinusoid velocity being sent as twist to px4. Px4 did not follow this sinusoid signal at all.

In the hopes that v1.11.0 Beta-2 would have the fix to this, I just switched px4 version from v1.10.1 to v1.11.0 Beta-2 using QGroundControl. I did not change anything related to the T265 or Mavros. As soon as I send odometry to the drone (the same way as I would be sending in v1.10.1), yaw locks into 90deg measurement, instead of 0deg as before.

My questions are:

• Is this expected behavior?
• If so, are there new parameters in v1.11.0 Beta-2 that sets the yaw angle of the external vision module?
• If not, is the new px4 version supposed to lose compatibility with mavros 1.2.0?
• If not, is this a bug?

To Reproduce
Steps to reproduce the behavior:

1. Drone switched on
2. Send identity pose and twist to the drone through mavros 1.2.0
3. Yaw will lock to 90deg in /mavros/local_position/pose, instead of 0deg
4. See error

Expected behavior
As I was used to px4 1.10.1, I would expect yaw to be locked to 0deg in this situation.

Log Files and Screenshots
What I'm sending as odometry:

 rostopic echo /mavros/odometry/out -n 1
header: 
  seq: 557
  stamp: 
    secs: 1593225174
    nsecs: 419409037
  frame_id: "odom"
child_frame_id: "base_link"
pose: 
  pose: 
    position: 
      x: -0.00226040370762
      y: 0.000924902502447
      z: 0.00186238042079
    orientation: 
      x: 0.00218730938341
      y: 0.0281774186185
      z: -0.000303314629048
      w: 0.999600498578
  covariance: [0.1, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.1, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.1, 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.001]
twist: 
  twist: 
    linear: 
      x: -0.00244679755129
      y: 0.00121997631364
      z: -0.0105472787882
    angular: 
      x: -9.17091763433e-05
      y: 0.00141319952327
      z: -0.00355636125558
  covariance: [0.1, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.1, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.1, 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.001]

What mavros returns as local_position:

rostopic echo /mavros/local_position/pose -n 1
header: 
  seq: 2228
  stamp: 
    secs: 1593225235
    nsecs: 292605440
  frame_id: "d0001_odom"
pose: 
  position: 
    x: -0.00126949173864
    y: 0.00307247601449
    z: 0.0131711084396
  orientation: 
    x: 0.0175287486783
    y: -0.0182371881402
    z: -0.705577019667
    w: -0.708181693917

Drone (please complete the following information):

• Quadcopter

Additional context
Running ROS Kinetic on Ubuntu 16.04

[marcelino-pensa]

Is there any chance that this can be a mavlink version issue? I'm currently running release/kinetic/mavlink from https://github.com/mavlink/mavlink-gbp-release.git
Also, I have noticed the updates in https://github.com/PX4/Firmware/pull/14990/files, so I'm not sure if I'm on the right version of mavlink

[bresch]

@marcelino-pensa Thanks for reporting the issue, however we would need a logfile (if possible from boot) to debug.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[marcelino-pensa]

We finally got back to this, and it seems like the issue was with the parameter EKF2_MAG_TYPE. We were setting it to 5 - none, which was making the initial yaw to lock to 90deg.
We then changed this parameter to 0 - automatic and the problem went away. It seems like this is a bug, or am I missing something here?