You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Altitude estimate from the topic /mavros/altitude before and after acquiring home lock changes drastically. Although this sudden change is expected due to GPS altitude fusion, this can be catastrophic which I learnt the hard way.
While testing offboard mode, my sequence of steps are as follows (All these steps are automated in an offboard node i.e, all I had to do is turn on the drone and the drone will take care of executing each of the mentioned steps below(except of course for step 3)):
Arm
Takeoff (3m above ground)
Wait for switch to OFFBOARD mode from RC
Execute the path
While in step 2 (takeoff), the code generates altitude based on the current altitude estimate from /mavros/altitude topic. This altitude from the mentioned topic can be different depending on whether home position lock was acquired or not as explained below:
Home position lock not acquired: In this case /mavros/altitude outputs barometric altitude.
Home position lock acquired: In this case, barometric altitude is fused with GPS and a new estimate is put on the topic /mavros/altitude.
Log Files and Screenshots
Log analysis when starting the script after home lock is acquired: link
Log analysis when starting the script before home lock is acquired: link
Note that step 2 (takeoff) altitude setpoint is of 3m. In the first log, you can clearly see that 3m altitude setpoint is relative to fused altitude whereas in the second log, you can see that it is way off.
Additional context
We were testing simple path execution via offboard mode.
The text was updated successfully, but these errors were encountered:
Just to clarify, the EKF isn't fusing the GPS altitude in you case because EKF2_HGT_MODE is set to barometric altitude. However, yes, the altitude is adjusted when the GPS altitude is acquired. Could you simply check for the validity of the global position solution before generating your path?
Describe the bug
Altitude estimate from the topic
/mavros/altitude
before and after acquiring home lock changes drastically. Although this sudden change is expected due to GPS altitude fusion, this can be catastrophic which I learnt the hard way.While testing offboard mode, my sequence of steps are as follows (All these steps are automated in an offboard node i.e, all I had to do is turn on the drone and the drone will take care of executing each of the mentioned steps below(except of course for step 3)):
While in step 2 (takeoff), the code generates altitude based on the current altitude estimate from
/mavros/altitude
topic. This altitude from the mentioned topic can be different depending on whether home position lock was acquired or not as explained below:/mavros/altitude
outputs barometric altitude./mavros/altitude
.Log Files and Screenshots
Note that step 2 (takeoff) altitude setpoint is of 3m. In the first log, you can clearly see that 3m altitude setpoint is relative to fused altitude whereas in the second log, you can see that it is way off.
Additional context
We were testing simple path execution via offboard mode.
The text was updated successfully, but these errors were encountered: