Hi
We have been flight testing for a while, and last week, we found some behaviour we don’t fully understand. We were flying in Mission Mode for a few hours, then we had a few seconds in Manual Mode and then back to Mission. As expected, during manual, the plane dropped some altitude, which it started to recover when back in Mission, but it seems to then stop following waypoints.
In the log, we can see that it looks like it receives a refresher of the altitude setpoint when it goes back to mission, but the x-y plot clearly show that it misses its turn, so it had to be taken over by our safety pilot since we had no idea if it was planning to continue on its course or eventually turn.
Is this expected behaviour? Does it not remember it’s waypoint after changing to manual and back?
We currently fly v1.12.3.
It’s hard to understand exactly what was happening with the description and screenshots you provided, is there the chance to get access to the log file?
Does it not remember it’s waypoint after changing to manual and back
It should keep the last waypoint as active and switch to tracking that again once back in Mission mode.
Hi. More investigations does not get me closer to an answer. The switch to manual in the log is not a pilot initiated switch (the RC was not touched at that point, as you also can see by all the stick inputs as constant, and the flight mode switch not passing by “stabilize” mode which it does when the switch is physically used). So we have two unknowns here, one is the switch to manual, which has happened by itself, the other is the system apparently not following waypoints. Looking at the telemetry log in QGroundControl, the x-track error is increasing once it passes the waypoint, but I don’t have much tools to check more thouroughly.
The reason for it crashing in stabilize is that it was out of sight, into the sun, and getting so far away that the flight had to be terminated before it got further, so that part is not of interest to analyze.
The switch to manual in the log is not a pilot initiated switch (the RC was not touched at that point, as you also can see by all the stick inputs as constant, and the flight mode switch not passing by “stabilize” mode which it does when the switch is physically used).
I read a different story in the log, there the RC input and manual_control setpoint correspond to the nav_state change of the vehicle when the vehicle changes from mission to manual (5s), then back to mission for 10s, then to stabilized for 15s until the crash.
Where do you do see that the “flight mode switch not passing stabilized”?
the other is the system apparently not following waypoints.
From what I see it does:
The moment you switch back to Mission the same position setpoint is tracked than prior the switch to Manual (the one in the bottom left corner). As the vehicle dropped about 60m in Manual, the waypoint’s altitude is though not accepted, which makes the place fly straight through the waypoint (see wp_dist), and then it slowly begins to bank left to start “loitering up to wp altitude” - only the pilot takes over in Stabilized then before the turn is really visible.
Thanks for looking at it. I see what the log states. However, the thing is that the physical switch on the transmitter actually did not move when the log say it did. To be very specific, the transmitter is inside a “mitton” because of the cold weather, the switch is on the front (and we have tested and confirmed it cannot be switched by accident by rubbing against the mitton since there is another (not active) switch that sticks out further just by it) and the only way to swithc it is to hold the hands on the sticks as normal during manual flight, and flip the switch with ones finger. Both our pilot is clear, but in addition, the lack of stick movement underlines that there is no holding of the sticks during this time.
My comment on “flight mode switch not passing stabilize” I mean what you see when the switch is registered to go from manual to mission, then there are some samples with stabilize, since it is a 3 position switch and it physically will pass the center position between the outer positions. I cannot see the same behaviour the other way, and in other logs we are used to seeing this.
Thanks for interpreting the second part. That is good news, it seems we have to redesign our flight pattern to ensure we have more time in cases like this to avoid running out of airspace.
Okay, then there could have been something off with the RC/the switch, I’m just interpreting the data in the log. You’re correct with it seemingly skipping the Stabilized mode slot, that could further indicate that something is off with the switch or the data the flight controller receives from the receiver.
Hope you’re soon up in the air again, and don’t hold back with questions if something on the flight controller side is behaving weird again!
