GPS and Nav data over Mavlink and pymavlink


Trying to send GPS_Input via pymavlink and include yaw input

I made a sample script (enclosed) which sends the GPS_Input ( #232 ) and it works but without yaw.

If I add the last parameter, yaw, as outlined in ( #232 ) I am getting an error that there are too many parameters.

I am not sure what I am doing wrong, it seems that the script is using an older version of the gps_input instead of the Mavlink V2. I enforced the mavlink version 2 by adding a parameter in the connection opening function but it does not seem to help in using the correct function.

master = mavutil.mavlink_connection(f'udpin:', source_system=1)

and then:

def send_gps_data(lat, lon, alt, yaw, fix_type=3, satellites_visible=10):
    msg = master.mav.gps_input_encode(
#    msg = master.mav.gps_input(
        0,  # Timestamp (not used)
        0,  # GPS ID (not used)
        0,  # Ignore flags (not used)
        fix_type,  # Fix type: 3 = 3D fix
        int(lat * 1e7),  # Latitude (scaled to 1e7)
        int(lon * 1e7),  # Longitude (scaled to 1e7)
        alt,  # Altitude in meters
        0.1, 0.1,
        0.01,0.01,0.1, #vn ve vd
        0.001, 0.001, 0.001, #spac, hac, vac
        satellites_visible  # Number of visible satellites
#        yaw * 1e2

What should I do to have yaw included in the GPS_Input?

thank you

Check that you’re using the latest version of pymavlink (2.4.39).

1 Like

Hi Stephen
Thank you, I was indeed using previous version.
After the upgrade with
pip install pymavlink --upgrade

and running the code without error

Thank you , I appreciate the help

Hi Stephen

If you could help me further.
I am sending now the mavlink commands and ArduPilot receives it as shown in Mission Planner Mavlink inspector. However, the ArduPilot still uses internal gyro for navigation.
Would you know how to disable the internal gyro and activate the YAW value given by the GPS_input command Thank you in advance

I filed another post on this topic in Ardusub

The internal gyro cannot be disabled. It’s a core part of the EKF fusion process. External measurements (GPS, Vision, etc) are fused with the IMU to estimate the vehicle’s position and orientation.

What you might mean is the EKF Source, where you can specify the external measurement source of the position, velocity and yaw: EKF Source Selection and Switching — Copter documentation

1 Like

Hi @stephendade

The internal gyro cannot be disabled. It’s a core part of the EKF fusion process. External measurements (GPS, Vision, etc) are fused with the IMU to estimate the vehicle’s position and orientation.

I think that is the key I was missing all the time. Thank you for that.

If the internal gyro is always providing yaw input to the KF, whatever I am sending via GPS_Input is being blended with the internal one and some sort of result is being generated.
That is probably why I cannot see much changes on the screen.

Is there a parameter which can at least push down the significance of the internal gyro and promote the use of external yaw?

I found EK3_YAW_M_NSE and EK3_YAW_I_GATE parameter but they control the magnetometer. Is that yet another input for KF for yaw estimation? So now I have gyro, compass and external yaw? This is getting crowded.

What would be a right way to set it up promoting externally provided yaw like 99%?

thank you

Hi @stephendade

I confirm that when I give it enough time I see the heading of the vehicle converges to the exact value I am supplying in GPS_Input.
So I probably was getting it all the time but since it was blended with the internal gyro, I never noticed it working.
Thank you very much for your help.
Still, if you knew how to demote the internal gyro, so KF promotes the external yaw would be great.
thanks again

The question I’d be asking is “why are the gyro and GPS_Input giving different yaw values?” It’s a fundamental assumption of the EKF that all inputs reflect reality. If different inputs are giving different values, then one of the inputs must be incorrect.

Without seeing a log, I’d guess that the IMUs are aligning to north, as they do with no external source while the GPS is spinning up. The GPS fix is probably disregarded for some period while HDOP remains high, which is especially common in less than ideal environments. So the “internal” value persists for longer than the user expects, despite some elements of telemetry displaying a valid external orientation.

Hi @stephendade

It is a good question.
The installation which I have contains much higher grade Nav system with a dual GNSS antenna which I want to use. I want to simplify the setup that there is only one GNSS/INS system for configuration and maintenance. I don’t like the idea of having two GNSS INS systems on one vessel.
So basically the internal gyro of pixhawk in general can show whatever values as it can be located in whichever position. But now it seems that I will have to locate the pixhawk in more or less correct position so the gyro can aid the navigation as I cannot turn it off completely.

Hello @stephendade, I have a different scenario but same issue.

I have implemented a SLAM algorithm for external nav data running on a host PC.
I’m attempting to run record rosbags to test my system. And as the ardupilot is not moving along with the SLAM localization, the drone on missionplanner is only aligned to one direction.

Is there a possibility to rectify the yaw alignment when simulating the localization by external navi?

You’re using a real system with simulated SLAM inputs?

You can’t mix real (the IMU on the system) and simulated inputs.