Px4-autopilot: [question] Mavlink GPS

[dakejahl]

Why do we use vehicle_gps_position in mavlink? This means mavlink is sending the data from the first GPS it finds rather than the blended solution from the EKF (ekf_gps_position)

[Antiheavy]

seems you'd want both.

[dakejahl]

Do you though? Maybe if ekf_gps_position isn't available it would send the first gps, but if the ekf solution is available I'd think you'd only care about that.

[JacobCrabill]

Right, in your GCS you'd like to see the GPS data that the controller is actually using; I suppose some extra handling of multiple GPSs could be done on the GCS side but that would be more work than simply sending the "correct" GPS data.

[Antiheavy]

Not to jump onto this issue, but there QGC issues might be related to this topic:
https://github.com/mavlink/qgroundcontrol/issues/6811
https://github.com/mavlink/qgroundcontrol/issues/6871

[Antiheavy]

I suppose some extra handling of multiple GPSs could be done on the GCS side but that would be more work than simply sending the "correct" GPS data.

I'd advocate to send all the data and let the GCS implementation decide how to best present the information for the particular use case. A super simple, easy to use drone, might want to only use the combined EKF solution. A more advanced drone might want to present more information of how different parts of the system are performing, or not performing for troubleshooting.

[dakejahl]

to play devils advocate.... I don't think we should send any more data than we need onto our already bandwidth constrained link

[JacobCrabill]

Yeah I would argue that if you need all that extra sensor data, use the binary logs on the SD card. Perhaps an option to enable multi-GPS streaming from PX4 would be nice for high-bandwidth links (or to a companion computer), but the default should just be to send all basic data that goes into the EKF.

[LorenzMeier]

As these streams can be configured individually I don't see the issue here. There is also a message for the fused estimate. I'm closing this accordingly. On a sidenote: Most commercially relevant systems are moving to higher-bandwidth links. While you should always be cautious of bandwidth, most operators do require video and MAVLink traffic becomes a rounding error.

For the ones that don't: You can always change the message rate configuration.

[dakejahl]

So the original question is still unanswered. Let me rephrase it:

Which should we use?

• ekf_gps_position
• vehicle_gps_position (sends first instance)

to display the vehicle location in the GCS?

[dagar]

So the original question is still unanswered. Let me rephrase it:

Which should we use?

• ekf_gps_position
• vehicle_gps_position (sends first instance)

to display the vehicle location in the GCS?

I would propose vehicle_gps_position, which would become the system's notion of GPS position (either voted primary or blended). https://github.com/PX4/Firmware/pull/13584

At the moment that's effectively ekf_gps_position in most cases, but I really don't think sending raw sensor readings out over mavlink should be dependent on a specific estimator.

[LorenzMeier]

I think there is some general confusion here:

1) The GPS position is a SENSOR!!!, not a state estimate. It is NOT being used in the GCS (except as fall-back)
2) The actual vehicle position is sent here: https://github.com/PX4/Firmware/blob/e5d30c441317399658d1d7eded9eb299b7cd5e9e/src/modules/mavlink/mavlink_messages.cpp#L2402

[JacobCrabill]

Except that it's also sent out here:
https://github.com/PX4/Firmware/blob/e5d30c441317399658d1d7eded9eb299b7cd5e9e/src/modules/mavlink/mavlink_messages.cpp#L1633

Which also gets picked up by QGC, last I knew.

[dagar]

@JacobCrabill both raw gps (vehicle_gps_position) and the global position estimate (vehicle_global_position) are sent. For position display QGC uses vehicle_global_position over vehicle_gps_position if available. Additionally QGC does use raw GPS to display the satellite count, etc, which users often pay close attention to (for better or for worse). With that it mind, I do think it's worth considering if the GCS should be displaying what the system is actually using for GPS data, and not arbitrarily pinned to the first instance regardless.

Personally I think https://github.com/PX4/Firmware/pull/14447 would cleanly resolve the issue, but it does get a bit messy if someone (dual gps setup) truly wanted to see both raw data sources plus the blended value (or even voted/selected) that the estimator was using. Mavlink has no mechanism to indicate how any of this is actually being used, so regardless of link rate I don't like the idea of simply sending all raw sources.

Let's continue any further discussion in https://github.com/PX4/Firmware/pull/14447.