WIP: mavlink GPS_INPUT support #10093

dagar · 2018-07-30T17:31:54Z

No description provided.

Antiheavy · 2018-07-31T02:13:26Z

Related comment in the dual GPS PR:
#9765 (comment)

Antiheavy · 2018-08-15T23:02:48Z

One issue that came up is how to handle GPS modules that do not send the expected altitude datum format for PX4/EKF2. For example, we might use a GPS receiver that only outputs wgs84 altitude, this is a problem for PX4/EKF2 which is expecting whatever uBlox "amsl" datum is (I think egm96?).

One idea is to send the MAVlink message to ignore the GPS altitude from the secondary MAVlink GPS source (param 1): https://mavlink.io/en/messages/common.html#GPS_INPUT_IGNORE_FLAGS
Another idea is that we send a artificially very large EPV value from the secondary MAVlink GPS source so that the driver and/or estimator will effectively ignore the GPS altitude, but use the other information from the secondary GPS.

Both of the above ideas would only be useful when switching to the secondary GPS, the primary GPS would need to have proper altitude and everything else for system initialization, pre-flight checks, pre-arm checks, etc.

Another approach could be to add a parameter to select which uBlox altitude value to use. Default to the current (egm96?), but allow an advanced user to select the wgs84 altitude so that it could match the wgs84 altitude on a secondary GPS module.

@jonrwat @priseborough @dagar

LorenzMeier · 2018-08-16T16:35:54Z

Could you please rebase? Thanks!

jonrwat · 2018-08-23T17:05:00Z

Several updates are recommended:

Scaling of values is incorrect (e.g. vel-ned). It looks like the majority of the GPS_INPUT handler was copied from the HIL_GPS handler, which has a different scaling of data. Scaling of parameters is specified at: https://github.com/mavlink/c_library_v2/blob/master/common/mavlink_msg_gps_input.h#L7
All data has not been copied to the "vehicle_gps_position" structure and published (e.g. hdop, vdop). This is apparent when looking at GPS status in QGC (both GUI display and MAVLink Inspector), as fields are missing (i.e. locked as zero).
The software doesn't use the GPS_INPUT message 'ignore_flags' field. This causes the system (and EKF) to potentially use data which is invalid. This likely isn't as great of a concern on platforms where all source data is supplied in a single message (e.g. u-blox UBX_NAV_PVT) but has greater concern on platforms where source data is fragmented across multiple messages (e.g. Swift Piksi). I'm not sure what the final solution is; but it seems harmful to feed known invalid data into the EKF.

@dagar

TSC21 · 2018-11-25T21:10:14Z

Jenkins test this please.

TSC21 · 2018-11-25T21:13:28Z

@dagar maybe we can rebase this on master?

@jonrwat we are probably bringing this as is now. We thank you if you can issue a PR with the changes you propose after it. Thanks!

dagar · 2019-02-04T16:07:10Z

Rebased on master. We could probably do a quick pass and get this in safely.

stale · 2019-07-10T18:36:46Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Antiheavy · 2019-07-11T01:27:36Z

Still a valid issue

stale · 2019-10-09T01:49:14Z

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

julianoes · 2019-10-09T06:12:32Z

src/modules/mavlink/mavlink_receiver.cpp

+	gps.lon = gps_input.lon;
+	gps.alt = gps_input.alt;
+	gps.eph = (float)gps_input.horiz_accuracy * 1e-2f; // from cm to m
+	gps.epv = (float)gps_input.vert_accuracy * 1e-2f; // from cm to m


The spec says this is all meters, not cm.

https://mavlink.io/en/messages/common.html#GPS_INPUT

julianoes · 2019-10-09T06:12:39Z

src/modules/mavlink/mavlink_receiver.cpp

+	//gps.vel_m_s = (float)gps_input.vel * 1e-2f; // from cm/s to m/s
+	gps.vel_n_m_s = gps_input.vn * 1e-2f; // from cm to m
+	gps.vel_e_m_s = gps_input.ve * 1e-2f; // from cm to m
+	gps.vel_d_m_s = gps_input.vd * 1e-2f; // from cm to m


julianoes · 2019-10-09T06:13:54Z

src/modules/mavlink/mavlink_receiver.cpp

+	gps.vel_e_m_s = gps_input.ve * 1e-2f; // from cm to m
+	gps.vel_d_m_s = gps_input.vd * 1e-2f; // from cm to m
+	gps.vel_ned_valid = true;
+	//gps.cog_rad = ((gps_input.cog == 65535) ? NAN : wrap_2pi(math::radians(gps_input.cog * 1e-2f)));


That's not a thing right?

julianoes · 2019-10-09T06:14:02Z

src/modules/mavlink/mavlink_receiver.cpp

+	//gps.cog_rad = ((gps_input.cog == 65535) ? NAN : wrap_2pi(math::radians(gps_input.cog * 1e-2f)));
+
+	gps.fix_type = gps_input.fix_type;
+	gps.satellites_used = gps_input.satellites_visible;  //TODO: rename mavlink_hil_gps_t sats visible to used?


Too late now, I think.

stale · 2020-01-07T06:33:52Z

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

LorenzMeier · 2021-01-10T17:11:12Z

Stale, closing.

dagar force-pushed the pr-mavlink_GPS_INPUT branch from c6429cb to 9cd5f30 Compare August 18, 2018 02:36

TSC21 closed this Nov 25, 2018

TSC21 reopened this Nov 25, 2018

WIP: mavlink GPS_INPUT support

ab23494

dagar force-pushed the pr-mavlink_GPS_INPUT branch from 9cd5f30 to ab23494 Compare February 4, 2019 16:06

dagar added the Admin: Enhancement (improvement) 💡 label Feb 4, 2019

weekly-digest bot mentioned this pull request Feb 10, 2019

Weekly Digest (3 February, 2019 - 10 February, 2019) #11425

Closed

stale bot added the Admin: Wont fix label Jul 10, 2019

stale bot removed the Admin: Wont fix label Jul 11, 2019

weekly-digest bot mentioned this pull request Jul 14, 2019

Weekly Digest (7 July, 2019 - 14 July, 2019) #12474

Closed

stale bot added the stale label Oct 9, 2019

julianoes requested changes Oct 9, 2019

View reviewed changes

stale bot removed stale labels Oct 9, 2019

weekly-digest bot mentioned this pull request Oct 13, 2019

Weekly Digest (6 October, 2019 - 13 October, 2019) #13171

Closed

stale bot added the stale label Jan 7, 2020

LorenzMeier closed this Jan 10, 2021

LorenzMeier deleted the pr-mavlink_GPS_INPUT branch January 10, 2021 17:11

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

WIP: mavlink GPS_INPUT support #10093

WIP: mavlink GPS_INPUT support #10093

dagar commented Jul 30, 2018

Antiheavy commented Jul 31, 2018

Antiheavy commented Aug 15, 2018

LorenzMeier commented Aug 16, 2018

jonrwat commented Aug 23, 2018 •

edited

Loading

TSC21 commented Nov 25, 2018

TSC21 commented Nov 25, 2018

dagar commented Feb 4, 2019

stale bot commented Jul 10, 2019

Antiheavy commented Jul 11, 2019

stale bot commented Oct 9, 2019

julianoes Oct 9, 2019

julianoes Oct 9, 2019

julianoes Oct 9, 2019

julianoes Oct 9, 2019

stale bot commented Jan 7, 2020

LorenzMeier commented Jan 10, 2021

WIP: mavlink GPS_INPUT support #10093

WIP: mavlink GPS_INPUT support #10093

Conversation

dagar commented Jul 30, 2018

Antiheavy commented Jul 31, 2018

Antiheavy commented Aug 15, 2018

LorenzMeier commented Aug 16, 2018

jonrwat commented Aug 23, 2018 • edited Loading

TSC21 commented Nov 25, 2018

TSC21 commented Nov 25, 2018

dagar commented Feb 4, 2019

stale bot commented Jul 10, 2019

Antiheavy commented Jul 11, 2019

stale bot commented Oct 9, 2019

julianoes Oct 9, 2019

Choose a reason for hiding this comment

julianoes Oct 9, 2019

Choose a reason for hiding this comment

julianoes Oct 9, 2019

Choose a reason for hiding this comment

julianoes Oct 9, 2019

Choose a reason for hiding this comment

stale bot commented Jan 7, 2020

LorenzMeier commented Jan 10, 2021

jonrwat commented Aug 23, 2018 •

edited

Loading