@RicardoM17 can you help me understand what you mean? What time of the log are you looking at? And was it a crash or just an unusual behavior you saw?
Hello @JulianOes . I’m just reporting another instance of the same issue.
In a nutshell when the drone switches from Offboard to HOLD mode it drops in altitude 1+ meter, in a seemingly incomprehensible way as the altitude estimate follows the reference, so it looks like the drone wants to go down but this is not expected. the same happens with the z velocity. In the log I shared (link here again for clarity: https://logs.px4.io/plot_app?log=fe20676a-5e55-4332-9f4d-c214b291dd03 ) this happens at 7:56.
Especially this plot:
We’re still trying to get to the root of this issue but no luck so far.
1 Like
Ok, now I understand what you mean, thanks. I have no idea why this happens though.
@bresch have you seen this before? Could this be something that is fixed with master/v1.12?
I just had a quick look and I cannot tell that this is the issue because the logging rate is too low, but it could well be that the altitude of the setpoint triplet is still at 0m when the loiter mode is engaged. This would explain why the trajectory setpoint initially goes down and then comes back to the desired altitude.
Thanks for having a look @bresch . I believe high rate was enabled for this flight (please confirm if that’s not the case) but unfortunately the SD card was not the one as recommended, so most likely that is the issue that you faced during your analysis.
We’ll try to get you a log without this issue.
If the cause is indeed as you’ve said does this mean that this should be fixed somewhere in the firmware? Or what else could it be?
@JulianOes Unfortunately not, I reported a new issue on Slack and I copy here the report to keep a track of the issue
This time, the drone descended 4 meters while in Hold mode!
Here is the log with the altitude loss at 7:02
https://logs.px4.io/plot_app?log=7981ca00-b894-4d2d-9da3-7165b2446d25
and here is another flight where there is no such behaviour when we exit the “Offboard” mode
https://logs.px4.io/plot_app?log=d887039c-ba23-4695-b847-946c873e1f9a
@JulianOes’s comment “It basically follows the estimation, until then it suddenly recovers.” had me think of a similar issue we’re facing recurrently, so I’m wondering if the two cases share the same root problem.
Our case is a switch from Mission to RTL after a Quadchute on our VTOL. The drone just flies in whatever direction (can be horizontal or vertical) it just happens to be flying for about 10s before it suddenly remembers that that’s not the way it’s supposed to go, then flies back to where the quadchute was triggered and only then actually executes the RTL as expected. Here’s a nice example: https://logs.px4.io/plot_app?log=afa2b9c2-741d-4eae-97b0-043fc23572fe
The front transition timed out at 9:01, causing a quadchute with RTL. But until 9:20 it continues in the direction it was flying during the transition. It tracks correctly the velocity setpoints (after the initial quadchute reaction). 6m/s is our MC cruise speed. In this occurrence the drone flew almost 100m away from home in RTL mode before turning around! Also interesting to see that the cpuload drops at 9:10 (when it’s only drifting) and then rises again at 9:20 when it starts to come back.
I think there’s something in the Hold/RTL mode initialisation where the expected setpoint is not correctly transferred to the MC position controller. Maybe something also related with a flight task switch / initialisation? I’m not very familiar with the flight task architecture, but it looks like in Mission mode the trajectory generation is done in velocity control and then the local position setpoint is retrofitted from it to get a graph that tracks so nicely. Now I’m wondering if in RTL + Hold modes these velocity setpoints do not correctly get reinitialised for the new target position and override the position setpoint by still retrofitting.
The above log is on v1.12-beta5 on a Pixhawk 4 with the recommended SanDisk Extreme U3 32GB.
The big difference to the two cases is that in our case it continues more or less in the direction it was already flying at before the mode switch, whereas in your case the z velocity setpoint in offboard mode before switching to Hold was almost zero and then in Hold it grew…
I also had some similar issues with PX4 v1.10 but have not been able to reproduce on v1.11 (not sure it was exactly the same issue as it was about 1 year ago).
In your logs, we can see that the setpoint_tripplet is not valid while entering hold mode. This case is not handled correctly in v1.10.
In v1.11, it is fixed by this commit: FlightTaskAuto: accept invalid triplet_setpoint (and interpret as loi… · PX4/PX4-Autopilot@e939f60 · GitHub
Cherry-picking this commit to my branch based on v1.10 fixed my issue.
It is working fine for me but I am not sure there is no hidden side effect…
1 Like
This is an interesting feedback ! I’ll update to v1.11 or later and see if I can still reproduce the error.