iNavFlight
Waypoints go to completely wrong altitude - 25ft
PLEASE MAKE SURE YOU READ AND UNDERSTAND THE SOCIAL MEDIA SUPPORT CHANNELS. QUESTIONS ABOUT FLASHING, CONFIGURING, PILOTING MAY BE CLOSED WITHOUT FURTHER INTERACTION.
Please double-check that nobody reported the issue before by using search in this bug tracker. For Bug-Reports, please use the following template and provide as much information as possible. Bug-Reports that don't follow the template, might be closed unanswered. If you are not sure if you found a bug, ask for further input in the community channels or open a Github discussion.
PLEASE DELETE THE TEXT ABOVE AFTER READING AND UNDERSTANDING IT
Current Behavior
All working great and RTH too which is set to 150ft, well I went to fly first mission- set it to 35m. (114 feet) it took off and rose 25 feet, you can see it on my googles and then took off to plow into the tree :) Don't worry, I Immediately disarmed and saved it...but that was scary, also it flew pretty darn fast like a racer!! - yes I should have tried in an open field :) Waypoint 1 is same place I took off from so it should have went to the set 35m (set to 3500cm)...so it should have just went up...but it acted like it thought it was at 35m, it didn't even make 35 feet, just 25 feet as shown in the googles. I am set to imperial, could this be the translation from imperial to meters is not working, but I tried setting back to metric and same issue.
Here is the scary video :) https://www.youtube.com/watch?v=LJBVhm-CnkU
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mission>
<version value="2.3-pre8"/>
<mwp cx="-82.<hidden>" cy="28.<hidden>" home-x="0" home-y="0" zoom="20.439297786746927"/>
<missionitem no="1" action="WAYPOINT" lat="28.<hidden>" lon="-82.<hidden>" alt="35" parameter1="0" parameter2="0" parameter3="0" flag="0"/>
<missionitem no="2" action="WAYPOINT" lat="28.<hidden>" lon="-82.<hidden>" alt="35" parameter1="0" parameter2="0" parameter3="0" flag="0"/>
<missionitem no="3" action="WAYPOINT" lat="28.<hidden>" lon="-82.<hidden>" alt="35" parameter1="0" parameter2="0" parameter3="0" flag="0"/>
<missionitem no="4" action="WAYPOINT" lat="28.<hidden>" lon="-82.<hidden>" alt="35" parameter1="0" parameter2="0" parameter3="0" flag="0"/>
<missionitem no="5" action="RTH" lat="0" lon="0" alt="0" parameter1="0" parameter2="0" parameter3="0" flag="165"/>
</mission>
Steps to Reproduce
Test waypoints, I never had v7 so this was 100% made on 8.01
Expected behavior
fly waypoints
Suggested solution(s)
idk
Additional context
https://pastebin.com/XLwjNu0S
Here is the scary video :) https://www.youtube.com/watch?v=LJBVhm-CnkU
version
INAV/TBS_LUCID_H7 8.0.1 Sep 10 2025 / 20:27:06 (e0dfe2c6)
GCC-13.2.1 20231009
It will only definitely achieve the set altitude at a waypoint if nav_wp_enforce_altitude is not set to 0 (the default). Otherwise it will climb at the set auto climb rate until it reaches the waypoint before moving on to the next waypoint regardless of whether or not the set altitude is achieved. So if waypoints are close together but there's a big altitude change the altitude may not be met. You need to take this into account when planning the mission, or use nav_wp_enforce_altitude if achieving the altitude is important.
Thanks, this is a quad, so I expected it to rise at or before wp1 like it does with Litchi (which is only supports DJI quads), but I need to remember iNav is for planes too :)
I have a similar inav 8.0.1 issue with a fast fixed wing. Thought at first it was due to poor altitude fix with gps so switched to using the barometer only. Altitude is correct in OSD and blackbox but the plane dives into the ground as though the waypoint destination height is below ground level. The explanation given by breadoven does not help with my issue. How can we see what altitude the craft is aiming for because it certainly does not match what was set in Mission Control where the Mission elevation Profile was fine. RTH behavior is correct.
I have a similar inav 8.0.1 issue with a fast fixed wing. Thought at first it was due to poor altitude fix with gps so switched to using the barometer only. Altitude is correct in OSD and blackbox but the plane dives into the ground as though the waypoint destination height is below ground level. The explanation given by breadoven does not help with my issue. How can we see what altitude the craft is aiming for because it certainly does not match what was set in Mission Control where the Mission elevation Profile was fine. RTH behavior is correct.
The target altitude is navTgtPos[2] in the log. The mission file would be useful.
I see navTgtPos[2] only sets to the requested 50m altitude after the crash. Before that the values just drop. I will attach the blackbox log and the diff all showing the mission profile. Greatly appreciate feedback on where I went wrong... apart from not being quick enough to pull up! :)
The mission above is using absolute altitude settings (P3 = 1) with WP 1 set to 314 m above sea level (not takeoff). Are sure this is the right mission file ... you mention a target altitude of 50m above ? In the attached log the GPS altitude is around 374m when the mission starts with an altitude relative to takeoff of around 66m. This means ground elevation at takeoff is around 308m (assuming flat flying area). So the WP altitude setting is only 6m above the ground which isn't enough unless you're very certain of the actual ground elevation at the waypoint.
There can be quite a bit of variation in map elevation vs actual elevation, then there's GPS error to take into account. You need to allow at least 30m margin or more when using absolute altitude settings and double check any measurement from mission planning software such as Mission Control actual matches real elevation to be sure the elevations make sense.
The 50m I referred to was incorrect. That was the RTH altitude. I had actually set an above ground height of between 50 and 100m for the WPs and the home take off point was at an elevation of approx 260m above sea level. You have the correct mission. I have flown this same area with another model using the same type of mission without difficulty many times. It is just flat farm land. What I don't understand is why navTgtPos[2] is a moving and rapidly descending target with the plane on it's way to the first WP, rather that a fixed altitude as it is as I switch to RTH. If you graph just the baro and navTgtPos[2] you will see what I mean.
WP missions use a linear climb/descent between waypoints so the target altitude is the incrementing altitude required to achieve the linear flight path rather than just the altitude at the next waypoint. One thing I did notice in the log is the nav state went to waypoint hold even though there's no hold point set in the above mission. The target altitude went to 0 at the same time. Not sure why it did that.
Perhaps I should try something like this to eliminate the sea level reference and see how I go:
Mission Control Waypoints [wp]
#wp 4 valid wp 0 1 457914670 93211323 10000 0 0 0 0 wp 1 1 457906142 93243295 10000 0 0 0 0 wp 2 1 457886392 93220550 10000 0 0 0 0 wp 3 4 0 0 0 0 0 0 165
Or perhaps it has something to do with my configuration using the barometer instead of the GPS for altitude. Grasping at straws here as I don't know inav's inner workings. Any other ideas I could try?
"WP missions use a linear climb/descent between waypoints so the target altitude is the incrementing altitude required to achieve the linear flight path rather than just the altitude at the next waypoint." Makes sense. OK so I am looking at the wrong thing. Inav really thought the WP was lower than the current altitude when this should not have been the case.
I am attaching another blackbox flight where I switched off the WP mission before it went the same way of the previous one. Another rapid drop!!!
The LOG00002.TXT mission appears to me to be correctly planned to provide c. 50 AGL across the whole mission plan.
What is strange is that after the initial turn to WP1 (white track is WP part). the vehicle then shows little interest in actually following the mission.
GPS interference? And yet there were plenty of satellites. I did swap out the GPS for a new one (HGLRC m100 pro) after this happened in previous attempts.
Stronnag, You might want to map the log3.txt to that waypoint mission. I think after the first failure I may (though memory fails) have modified the mission. Any other data required or actions to take to help solve this? I'm happy to go back to the flying field and collect more raw data if it helps.
Your problem appears to be:
- You generate an Absolute Altitude mission. From static terrain analysis, this should provide for c. 50m ground clearance.
- Your GPS consistently over-reports altitude by c. 50m.
- When you arm, INAV uses the GPS absolute altitude to generate WP relative elevations ... of c. 0m.
Flying:
- Thus, when you engage WP mode, you command INAV to fly the aircraft into the ground.
- INAV obeys your command.
Solution(s):
- Use relative altitude missions; and / or
- Ensure absolute altitude ground clearance exceeds the altitude error of the GPS.
For the 00002 log.
GPS altitude at arming = 314m
Mission absolute altitudes 314m, 315m, 318m, 314m, 320m, 307m.
Actual AMSL at arm point: 264m.
INAV just did that which you commanded it to do ....
Are you sure there isn't some sort of RF interference in that area? That's a large GPS altitude error and also the plane doesn't seem to want to actually head to the first waypoint in Log 00002. navTgtHdg is 350 initially whereas GPS ground course remains at 260 for some time although eventually it does seem to catch up with navTgtHdg, doesn't seem to want to turn.
Also it went into WP time Hold (Nav State = 35) just before the mission was cancelled when no hold is set. Although it didn't seem to work because navTgtHdg remained fixed from the moment it started. Can't see how this could happen. Geofencing perhaps ?
A Diff would be useful to check the settings.
Also it went into WP time Hold (Nav State = 35) just before the mission was cancelled when no hold is set. Although it didn't seem to work because
navTgtHdgremained fixed from the moment it started. Can't see how this could happen. Geofencing perhaps ?
This behaviour has been noted elsewhere (Discord).
Actually it would go to Timed Hold if nav_wp_enforce_altitude was active. I'm guessing it was related to this.
Just finished another 2 test flights. This time using relative altitude. The first (log11) was crazy! GPS interference galore. Shortly after the start WP mission, 0 satellites and emergency landing triggered. However the second flight (log12), was successful. I have attached the blackbox logs and a "diff all". It may be my GPS altitude problems stem from a new antenna tower in the area. A fellow club member had his helicopter go crazy just a few days ago and we are the only ones using GPS in our aircraft for the moment. So not an inav bug! Thanks for the assistance.
I notice nav_wp_enforce_altitude isn't enabled in the Diff. Was it enabled in the previous Log 00002 flight ? Hard to explain the WP Hold kicking in if it wasn't.
Yes, it was enabled in that flight at 5m. I then set it back to 0 (disabled). I have since found that solar storms with a Kp index above 3 were occuring during these flights, which could explain the erratic gps behavior.