Describe the bug
Drone is sent on an auto mission, instead of taking off 4-5m above ground, it lifts itself slightly above ground and hovers there.
To Reproduce
Mission that is run:
change speed cmd -> set roi cmd -> takeoff -> waypoint -> waypoint...
Note: this behavior happens to me less than once in 30 flights
Expected behavior
Normal takeoff to 5m above ground followed by other waypoints
Log Files and Screenshots

We see that the triplet type quickly switches from takeoff(3) to position(0), probably due to the detected takeoff.
Clearly the current triplet altitude is ~5m higher than the drone altitude, so normally the upwards velocity should be commanded by the flight task.
Additional context
MPC_TKO_RAMP_T = 0
MPC_TKO_SPEED = 1.5
MPC_SPOOLUP_TIME = 1
The "position control setpoint update failed" error might be related to:
https://github.com/PX4/Firmware/issues/13668
by the way I get this error on every mission start, and it normally doesn't effect the takeoff in such a way, although it might be a timing issue, such that it depends when the error happens.
Any help is in debugging and fixing the issue is appreciated
An issue I've seen recently is the following:
The issue is that the difference in position between the first and second home position can be up to a few meters and this is why it can be that the drone takes off at 1m instead of 4, or the opposite, or even getting the message "takeoff denied: above takeoff altitude" while being on ground.
@bresch Sounds like the first step is to tighten the requirements to set home depending on GPS accuracy. Second step would then be to make the QGC command relative.
I see, but I dont think thats the issue here.
In the plots you can see that the home position and the global position altitude are the same while the triplet altitude is 5m higher.
That would normally mean that the flight task got the altitude setpoint 5m higher than the drone position and should request an upwards velocity, instead the trajectory velocity is roughly 0.
I see, but I dont think thats the issue here.
In the plots you can see that the home position and the global position altitude are the same while the triplet altitude is 5m higher.
That would normally mean that the flight task got the altitude setpoint 5m higher than the drone position and should request an upwards velocity, instead the trajectory velocity is roughly 0.
Right, we'll have a look at that. Are you on top of current master? Or v1.10? Can you share a log file, or is it easily reproducible in SITL?
Its 1.10, I can share a log (on monday), its not easily reproducible at all, happened 2 times in 50 flights (real flights not sitl though). I did a bit of debugging but considering how hard it is to reproduce it, I only have a theory why it might have happened, cant say for sure. Will post it with the log file.
Even though the issue doesnt happen too often, its still significant for any autonomous operation since it requires a person at the site of operation to take over control.
I observed a similar behaviour:
Drone should do a mission with auto takeoff and then do a simple waypoint mission. But after takeoff the drone stops ascending after approximately one meter and starts hovering with the message from QGC: "Autonomy off! Returned control to pilot". The logs are here.
This behaviour has been observed several times.
You will see that it is a self build firmeware, but the changes (flarm driver) were nor active!
@NAmmann Based on the message you get that's a different trigger: "Autonomy off! Returned control to pilot" tells you that the joystick was moved while the drone was flying autonomously and hence the pilot is now back in control. Please check if you have a remote or joystick or QGC virtual joystick connected and moving a stick to trigger this. If you want to disable this feature set parameter https://dev.px4.io/master/en/advanced/parameter_reference.html#COM_RC_OVERRIDE to zero. If you have further issues with the RC override feature please open a separate issue and mention me, thanks.
@bresch Could this be related? https://github.com/PX4/Firmware/issues/13751
@MaEtUgR Could be, yes. I've also seen that: https://github.com/PX4/Firmware/issues/12264
This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.
@MaEtUgR This went stale - should it be closed?