Unable to set `EK3_GPS_TYPE = 0` when using mavlink HIL_GPS message

[vincekurtz]

Issue details

I am using a mavlink HIL_GPS message to send (fake) GPS data to the Ardupilot. Attempting to set EK3_GPS_TYPE to 0 results in the error: EK3: Changed EK3_GPS_TYPE to 1. The HIL_GPS message is generated from an Optitrack motion capture system via the mavros fake_gps plugin, and does include accurate 3D velocity information.

Version

3.6-dev

Platform

[ ] All [ ] AntennaTracker [ X] Copter [ ] Plane [ ] Rover [ ] Submarine

Airframe type

Quad-X

Hardware type

pixhawk 2.1

[vincekurtz]

If there isn't a particular reason for this behavior (assuming there is no vertical velocity from a HIL_GPS message), it should be an easy fix. I was able to successfully set EK3_GPS_TYPE to 0 after simply adding

state.have_vertical_velocity = true;

to line 135 of libraries/AP_GPS/AP_GPS_MAV.cpp.

[peterbarker]

On Thu, 22 Mar 2018, vincekurtz wrote:

EK3_GPS_TYPE to 1. The HIL_GPS message is generated from an Optitrack motion capture system via the mavros fake_gps plugin, and does include accurate 3D

Sorry, unrelated to your question here, but we're trying to add support into ArduPilot for more appropriate mavlink messages than HIL_GPS.

In particular, https://github.com/ArduPilot/ardupilot/pull/7980 add support for four different /position/ message types.

Are you able to test that support for us?

The fact that you're able to feed in velocities leads me to think we might need to support VISION_SPEED_ESTIMATE too....

[vincekurtz]

The original reason for using the HIL_GPS message was that despite its limitations, it's supported by mavros more or less out of the box. I'm definitely open to testing some better solutions though.

What would be most useful for our use case would be to get position/orientation information from a generic ROS geometry_msgs/Pose topic to the flight controller. I'm not sure if that's exactly what you have in mind with this new support, but I'd be glad help test things out wherever possible. Just let me know what would be helpful.

[WickedShell]

The main problem with flagging it as has vertical velocity is that if any HIL source does not provide that, it will lead to a lot of issues in the code (not just in the EKF). You could check that vertical velocity was non zero before you set the have vertical velocity flag to true which works, as long as you have a noisy enough environment (in a simulated noise free environment where there is no vertical velocity till the aircraft takes off this would still cause issues). Will requiring a non zero value before flagging it as true work for your case?

[vincekurtz]

Requiring a non-zero value does work for my case, but it's a bit awkward.

When I first start the stream of HIL_GPS messages (via mavros), EK3_GPS_TYPE gets changed to 1, suggesting zero vertical velocity. If I then go back and change EK3_GPS_TYPE to 0 it stays set to 0.

[Morris-ae]

hi, sorry I couldn't find EK3_GPS_TYPE in the new AC 4.2.3, I am trying to use Marvelmind indoor GPS, is it renamed? thanks in advance