Incorrect Altitude when using a Here 4 GPS in AUTO mode

Hello,

I am experiencing an altitude issue when using a Here 4 GPS in AUTO mode.

Hardware and setup:

  • Flight controller: Pixhawk Cube Orange Plus

  • GPS: Here 4

  • Firmware: ArduCopte (4.4.4) (latest stable at the time of testing)

  • Frame : Hexacopter

During AUTO flight, when I command a mission altitude of 5 m, the vehicle actually flies at approximately 8–9 m above ground. In the ground control station, the displayed altitude also reflects this higher value, resulting in a consistent altitude error of about 3–4 m compared to the altitude set in the mission. This offset appears even though the vehicle is flying steadily and the commanded altitude remains unchanged, indicating that the reported altitude does not accurately represent the true physical height of the vehicle.

This issue is only observed when using the Here 4 GPS. The problem appears specifically in AUTO mode, and it affects altitude tracking and mission execution accuracy.

Because of this incorrect altitude information, the vehicle does not maintain the expected height during autonomous flight.

I would like to know if this is a known issue with the Here 4 GPS altitude output or if there is any recommended configuration or parameter setting to correct this behavior.

Log.

More words

4.4.4 is pretty old firmware, you will need to provide a log before anyone can start to help.

Unless you set it for the altitude to be measured from the gps, the flight controller will use the baro for altitude. If you set the altitude to be measured from gps then you will have large swings in altitude.

Thanks for your reply.

We have configured the primary altitude source to GPS only, and this issue started after switching to the Here 4 GPS. Previously, we were using the Here 3 GPS with the same configuration and did not observe this problem.
We have also updated the bootloader as recommended by Philip Rowse CEO of CubePilot, but the altitude issue still persists with the Here 4.

Did you updated the Here4 firmware already?

Yes, only the Here 4 bootloader was updated, and this was done after we started experiencing the altitude issue.

Need a .bin log to tell more, otherwise we are just guessing.

I have attached the log files for this issue.
Please review them and let me know if you notice anything abnormal or if you can suggest any parameter or configuration changes to resolve the altitude problem.

Thanks for your reply.
I have attached the log files in my earlier response for the other replies in this thread—please have a look at those logs and let me know if you notice anything or can suggest any changes.

I have attached log files, please go through and let me know if there any changes to be done.

Just noticed this thread looks similar: Altitude Increase in AUTO mode

Don’t double post. It’s frustrating for those of us who volunteer our time here to help others.

If you aren’t using RTK then you should set the EKF back to baro. EK3_SRC1_POSZ,1.

You could also try setting EK3_ONG_HGT_MASK,5. You can read about it in the link below.

1 Like

I highly recommend updating the firmware to latest stable.

I would start by setting these, the last 3 will probably help a lot but ALL of these should definitely be set at once:

ATC_THR_MIX_MAN,0.5
BATT_FS_CRT_ACT,1
GPS_AUTO_CONFIG,2
GPS_GNSS_MODE,7
INS_ACCEL_FILTER,10
MOT_HOVER_LEARN,2
PSC_ACCZ_I,0.6
PSC_ACCZ_P,0.3

Protect the barometers from the prop wash, then they will be more useful and you wont need to rely on variable GPS altitude. It is the EKF’s job to decide on what is best to use.

See how it flies after all those changes, and probably run Autotune since tuning is not quite complete.

3 Likes

All of the points @xfacta raised are very important

1 Like

Thank you for the detailed suggestions and recommendations.

We will apply all the listed parameter changes together as you advised. We will also check the barometer protection from prop wash and avoid relying solely on GPS altitude so the EKF can properly manage the altitude source.

Here3; ; NEO-M8P stores the WGS84 geoid model

Here4+; NEO-F9P stores the EGM96 geoid model

Because the geoid models are different, there are altitude differences.

This is a troubling problem.

Even so that shouldn’t cause altitude changes in flight, maybe just a slight difference in reported altitude. To be honest I’ve not noticed any difference.
I believe @Nagarjun04 's problem is down to some incorrect parameters, lots of propwash over the baros and possibly incomplete tuning.

All the info I can find says “default: WGS84” for all the datum reference fields.
The integration manual does warn that “The NEO-F9P stores the EGM96 geoid model with limited resolution” (I believe) in the context that you’ve elected to use something other than WGS84.

In the Ardupilot code all GNSS comms assumes WGS84, and as far as I can see there is no mention of EGM96 or changing models.
Please let me know if you’ve got other information because I’m interested to find out more.