Heading Indication in WebUI

[laluzdiy]

I don't think this is really an issue but something I observed. On versions 5b3 and 5b4, the heading indication shown in the WebUI has a 90 degree quadrant that doesn't work. When slowly rotating the unit - the heading jumps between 135 degrees and 225 degrees (at least on my unit).

I don't think this information is used anywhere except the WebUI and if so it's not really an issue. Also the heading appear to be 180 degrees off. I'm assuming here that the forward direction on the RY835AI module should be side with the InvenSense, Honeywell, and Bosch sensors as that is the proper orientation for the AHRS pitch.

[ghost]

AHRS heading always initializes to 360°, regardless of the orientation of the sensor. Once Stratux gets a GPS lock and detects a ground speed greater than 7 knots, it will slew the heading to true course. That wasn't being handled right in 0.5b4, but #186 should resolve it.

Jumps could be caused by a low-accuracy GPS lock (i.e. you're stationary, but location shifts) causing a false ground track. The 7 knot filter will eliminate this 99%+ of the time unless reception is especially bad.

We're not doing anything with the magnetometer yet.

[cyoung]

I'm assuming here that the forward direction on the RY835AI module should be side with the InvenSense, Honeywell, and Bosch sensors as that is the proper orientation for the AHRS pitch.

That's correct.

[Nokomis449]

I had the same issue and it's still there in 5.5, as there is an area of the compass (mine seems to be roughly 110deg to maybe 210deg) that the paper airplane will not point to while sitting flat on the table and being slowly turned by hand. No GPS lock in the house.

[cyoung]

There's a calibration sequence that needs to be done for the MPU6050, the tools are on there if you're able to use the command line? If not it will be built in to either the web interface or automatic soon.

[ghost]

@cyoung -- this one isn't a calibration problem; it's due to libimu not properly handling the lack of compass input in the current codebase.

The Euler angle output from mpu9150, passed through libimu, should be 0 ± π radians (0±180°). What was being passed was 0 ± 0.75π radians (0 ± 135°) ... or 225° - 135° in compass heading.

Why the difference? mpu6050.c aligns gyro yaw to magnetic heading, using yaw_mixing_factor as a proportional gain to fuse the two inputs:

    deltaMagYaw = newMagYaw - newYaw;
        ...
    if (yaw_mixing_factor > 0)
        newYaw += deltaMagYaw / yaw_mixing_factor;

This mixing factor is taken as an argument by mpu9150_init(). Our problem lies in the fact that libmpu.c passes a constant -- in this case, "4". But, we're not using the mag compass input, so magYaw is always 0.

The net result is that the yaw output is reduced by a factor of 1/4, and that full-scale misses a full 90° of the compass.

The quickest fix short-term fix would be to update libmpu.h to change DEFAULT_YAW_MIX_FACTOR to 0. Make sure to force libimu to re-compile (or just delete the .o /.so files) when you make.

Longer-term we either get the magnetometer working (feed as I2C slave and/or switch to a 9150/9250) or update libimu and its go wrapper to pass the appropriate gain factor.

[skypuppy]

YIPPEE!

On 01/07/2016 10:03 PM, cyoung wrote:

There's a calibration sequence that needs to be done for the MPU6050, the tools are on there if you're able to use the command line? If not it will be built in to either the web interface or automatic soon.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/190#issuecomment-169887413.