While I test “param set SIM_GPS_BLOCK 1”, I notice that QGroundControl keeps show wrong altitude even though ArduPilot uses barometer as primary altitude sensor and still measures correct barometer sensor values.
It seems likely to me that displayed altitude on QGC is only depend on GPS. Thanks.
If QGC gets altitude from GLOBAL_POSITION_INT message it expects to keep getting it from there and shows those values. It won’t switch on the fly to using the ALTITUDE message only. If it never gets a GLOBAL_POSITION_INT message it will instead use ALTITUDE mavlink message.
All of that said, it’s unclear given what you are seeing whether what QGC does is correct or not.
Thanks for your prompt reply.
Let me explain details
GPS data blocked according to “SIM_GPS_BLACK” parameter. So, the drone had no local position info.
QGC shown the altitude was 66.9 meters which was last altitude data from GPS, but reliable altitude source was only one, barometer sensor in this situation.
VFR_HUD MAVLink messages correctly reported altitude as you see.
To sum up, it will be nice that QGC gets altitude from VFR_HUD/ALTITUDE when the drone loses GPS signals.
This is because QGC kept displaying the 66.9 meters even through the drone decreased altitude and then landed on the ground.
Yeah, let me ask the power that be in mavlink land what the correct way to do this is. It certainly seems like QGC is incorrect.
I’ve entered an issue for this: https://github.com/mavlink/qgroundcontrol/issues/8851. If you track that you should be able to know when this gets fixed.
Thanks for your a quick response!
So far in talking with the ArduPilot and PX4 firmware devs it seems like there is a problem with how SIM_GPS_BLOCK is implemented in PX4. Since GLOBAL_POSITION_INT sends “fused” values it should continue to be sent even after SIM_GPS_BLOCK is turned on. It’s my opinion that there is a bug in how SIM_GPS_BLOCK is implemented in PX4. I have confirmed that with ArduPilot GLOBAL_POSITION_INT is always sent even if you have no GPS at all for example.
So although I’m not getting a truly clear answer from the PX4 firmware folks yet it seems like QGC is doing the right thing and it shouldn’t try to track suddenly not getting GLOBAL_POSITION_INT messages since that shouldn’t happen.
Thank you for the update.
As far as I know, developers of PX4 have kept updating the sensor failure simulations (https://github.com/PX4/Firmware/pull/15063). I hope that the update will solve this problem.
Unfortunately, this issue still can be reproduced on master version of PX4.