Verifying GPS Use for Heading

dbitetto · July 28, 2024, 8:26am

Hi everyone,

I recently purchased the Holybro H-RTK Unicore UM982 GPS module and enabled GPS-based heading by setting the EKF2_GPS_CTRL parameter to 15. I would like to know how I can verify that the system is actually using GPS data for heading calculations instead of the compass.
What steps or parameters should I check to ensure that the configuration is correct and that the GPS is being used for heading?

Thanks in advance for your help!

JulianOes · July 28, 2024, 9:47pm

You can go to Analyze Tools → MAVLink Console in QGroundControl, and then do:

listener estimator_status_flags

And look for: cs_gnss_yaw

If you record a log, then you can look at it in PlotJuggler (or whatever tool you like) and look for ESTIMATOR_STATUS_FLAGS.cs_gnss_yaw.

github.com

PX4/PX4-Autopilot/blob/d841bf124fc3201c6d14add3ae65ce84187081d3/msg/EstimatorStatusFlags.msg#L29


      
          bool cs_ev_pos                # 12 - true when local position data fusion from external vision is intended
          bool cs_ev_yaw                # 13 - true when yaw data from external vision measurements fusion is intended
          bool cs_ev_hgt                # 14 - true when height data from external vision measurements is being fused
          bool cs_fuse_beta             # 15 - true when synthetic sideslip measurements are being fused
          bool cs_mag_field_disturbed   # 16 - true when the mag field does not match the expected strength
          bool cs_fixed_wing            # 17 - true when the vehicle is operating as a fixed wing vehicle
          bool cs_mag_fault             # 18 - true when the magnetometer has been declared faulty and is no longer being used
          bool cs_fuse_aspd             # 19 - true when airspeed measurements are being fused
          bool cs_gnd_effect            # 20 - true when protection from ground effect induced static pressure rise is active
          bool cs_rng_stuck             # 21 - true when rng data wasn't ready for more than 10s and new rng values haven't changed enough
          bool cs_gnss_yaw              # 22 - true when yaw (not ground course) data fusion from a GPS receiver is intended
          bool cs_mag_aligned_in_flight # 23 - true when the in-flight mag field alignment has been completed
          bool cs_ev_vel                # 24 - true when local frame velocity data fusion from external vision measurements is intended
          bool cs_synthetic_mag_z       # 25 - true when we are using a synthesized measurement for the magnetometer Z component
          bool cs_vehicle_at_rest       # 26 - true when the vehicle is at rest
          bool cs_gnss_yaw_fault        # 27 - true when the GNSS heading has been declared faulty and is no longer being used
          bool cs_rng_fault             # 28 - true when the range finder has been declared faulty and is no longer being used
          bool cs_inertial_dead_reckoning # 29 - true if we are no longer fusing measurements that constrain horizontal velocity drift
          bool cs_wind_dead_reckoning     # 30 - true if we are navigationg reliant on wind relative measurements
          bool cs_rng_kin_consistent      # 31 - true when the range finder kinematic consistency check is passing
          bool cs_fake_pos                # 32 - true when fake position measurements are being fused

I agree it would be nice if there was an easier way.

dbitetto · August 1, 2024, 4:37pm

Hi Julian,

I’m attaching these images. I did the test you mentioned, but it didn’t work. I see the parameter is set to false.

Any idea about this?
Maybe i have to disable or change other parameters?

JulianOes · August 1, 2024, 9:56pm

And that’s tested outdoor with good GPS signal, and you have verified that GPS itself is working properly?

petergerten · January 22, 2025, 1:11pm

I have exactly the same problem. GPS works but cs_gps_yaw shows false. Using UM982 dual antenna setup with latest px4 stable (1.15.2). Did you solve it eventually?