PX4 v1.8.x - FW Control lost after mission->stabilized->mission mode switch during landing

[fredowski]

On November 18th we have flown a X-UAV Mini Talon with a custom build firmware based on the release/1.8 branch plus x-uav mini talon airframe changes.

https://github.com/fredowski/Firmware/commit/da2a8db4672128a4e461296f472cc199b51db7aa

The flightplan included the fixed wing landing pattern composed of a loiter and the landing approach. The complete mission was flown in mission mode including hand launch. There were no problems during the mission. When the plane did the final landing approach after the loiter the pilot switched from "Mission" to "Stabilized" because he considered the altitude too high and wanted to try a second landing approach. He switched further to "Manual" and flew a turn and increased altitude. Then he switched back to "Mission" mode. The plane changed direction back to the loiter point which was part of the landing pattern.

When the plane reached the loiter point it did not turn to the landing point but continued with the heading to the loiter point and increased altitude. The pilot tried to give "Goto" commands via telemetry and QGC but the plane did not react. The pilot tried to change mode to "Return" but the plane did not react. At that point of time the plane was not visible anymore. The pilot did not try to switch mode to "Stabilized" or "Manual" and did not try to activate the "Kill Switch", so we do not know if that was still working.

The pilot team instead jumped into a car and tried to follow the plane in order to keep within the telemetry distance. The idea was to convince the plane to accept the "Return" or "Hold" command. They could get in contact after some kilometers again where the plane had already an altitude of 580m, but the plane did not stop. At that point of time the plane had enough battery for another 80km and we lost the plane.

I expect that switching to "Mission" will make the plane continue and resume the mission but not fly away. My guess is that this is related to the new landing pattern but I do not know if that introduced new features in the firmware or if this is just something in QGC.

I have a screencast of the telemetry replay: https://youtu.be/sMVWQqjsN-g

The telemetry log is here: 2018-11-18 11-44-05.tlog.zip

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Antiheavy]

@fredowski if this doesn't have anything to do with your customized firmware, I wonder if it is a fundamental bug with Land mode? When the pilot switched back to Mission mode, the active waypoint was still the Land waypoint, you can see that the vehicle started sending the "landing" flag down to QGC since the Abort slider pops up again. The vehicle is heading the opposite direction and is on the far side of the Land waypoint. It was tracking the land waypoint the whole time during the flyaway.

@dagar this wouldn't have anything to do with heading hold when past the Land waypoint would it?

[fredowski]

Hi @Antiheavy, thanks for your review. You are right, in this situation by coincidence the landing and the loiter point are in the same direction when the pilot switched back to mission. I thought it would fly back to this loiter point but you are right it could be direction of the landing point. The altitude however reaches 50m at the loiter point which is the altitude set point of this loiter point. The custom part of the firmware is the addition of the X-UAV Mini Talon airframe. I consider it very unlikely that that can explain the behaviour.

[1Gump]

i think that, if you had enough battery left, you'd eventually see the plane returning to the "land" from the other side of the map. imho, the plane should have a programmed distance limit from the "land" coord if it is flying in a different direction.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[julianoes]

Is there still follow up needed here or can we close this?

[Kjkinney]

This flyaway is repeatable in SITL. It appears to be caused by heading hold being triggered before the flair height is achieved. I am not sure why the plane climbs, but I am reasonably sure the heading hold is why it does not turn back.

What I do is allow the plane to achieve the landing slope, and then switch to stabilized mode to force the aircraft to overfly the land waypoint. The airplane will have entered the heading hold state, and pass the land waypoint at which point it starts climbing in a straight line.

Here is a log example of this: https://review.px4.io/plot_app?log=32089cac-66f1-4027-bd60-6edd60db12a9

The same test was also used with heading hold disabled and the plane did not fly away, but instead attempted to return to the land waypoint.

This log contains a landing with heading hold enabled, and a landing with it disabled: https://review.px4.io/plot_app?log=32089cac-66f1-4027-bd60-6edd60db12a9

These tests were done on a 1.8 based build. I have yet to test this on a master based branch.

@fredowski I recommend you disable heading hold by setting the distance to 0. This is our current approach and it works very well. Heading hold will need to be fixed to stop this from happening. An idea I have would be to force heading hold only at flare, removing the the horizontal distance parameter entirely.

FYI @julianoes

[fredowski]

@Kjkinney, thank you very much for looking into this issue and your effort to setup this scenario in simulation. Great work! It seems to explain the behaviour that we have encountered last November with our plane. By the way, you can watch the PX4 firmware in action in the mediterranean sea here in a TV report: https://www.hs-augsburg.de/searchwing/german-tv-reports-about-first-searchwing-drone-mission/

[1Gump]

I have some experience with this behavior - almost lost a plane! since then, I've moved to 1.9 and haven't tested it because i'm using a config that works for me (landing "pattern") and a FS that returns to this pattern rather than RTL. The "pattern" forces a direction, height and distance that can accommodate the slope & speed. see this link for more details of my experience... Topic (PX4 Autopilot): Plane Flyaway recovery: RTL loiter then flew away https://discuss.px4.io/t/plane-flyaway-recovery-rtl-loiter-then-flew-away/10991?u=1gump

[Kjkinney]

@1Gump what is your heading heading distance? It's the parameter FW_LND_HHDIST. If you want to completely avoid these, set that to 0.

[fredowski]

Hi @1Gump, do I understand the problem in issue #12035 right, that you switch off your RC to trigger the failsafe that you have configured to be RTL. RTL is configured to last loiter for 45 seconds. Everything works, i.e. loosing RC triggers failsafe (RTL). But after 45 seconds the plane leaves the loiter and flies away. What would be your expected behaviour? Loiter for ever?

[1Gump]

Hi @1Gump, do I understand the problem in issue #12035 right, that you switch off your RC to trigger the failsafe that you have configured to be RTL. RTL is configured to last loiter for 45 seconds. Everything works, i.e. loosing RC triggers failsafe (RTL). But after 45 seconds the plane leaves the loiter and flies away. What would be your expected behaviour? Loiter for ever?

you got it all the way up to the post-45 seconds part. I programmed the plane to loiter at "L" (launch) for 45 seconds, then land (at the land WP). sometimes it 'appeared' to head towards the landing WP, and even dip as if to try and descend. sometimes it just exited the loiter and headed in a completely random direction. I regained control by toggling the mode. I used an RC Tx to toggle the mode, but I also test having the geofence violation set to "loiter" (instead of RTL) and this worked - is that due to a mode toggle - I think so, because geo violation set to RTL had no affect. at any rate, I do agree that it appeared to get locked into a heading hold if it passed the land WP (or flair? -Kjkinney). if it continued, it seemed to climb aggressively in that heading. ... just to be clear, I repeated the condition of geo violation set to RTL and it had no affect on turning the plane around when locked into this HH flyaway condition. I do not recall if any of my tests had RTL initiated by geo violation or if they were all RC Tx disconnect (I did not document these tests and they were a ways back :0 . there was a condition in my tests that I did not test that may affect the results, and that is to move the RTL point far enough away from the land WP to allow the loiter altitude - to - land wp sufficient distance to achieve the maximum slope and flair. I think my points were too close to one another for that. ... what I use now (discovered this afterwards by accident) ...the "landing pattern" forces the math to be correct for the slope from the loiter to the land wp, so the plane should not overshoot because of alitutde (mine hasn't yet). the "pattern" also sets up a direction - which is key for a runway or similar situation. RTL did not do either of these things. my failsafe, now, is programmed to land by the "landing pattern". since this pattern is always (to this point) close to me, I assume that I will regain RC Tx control because of proximity, or the plane will land if the RC Tx (or link) is dead, or I just want it to land. . @Kjkinney ..i will think about setting the HH to 0. what is this HH good for, anyway?

[Kjkinney]

@1Gump heading hold originally existed to force the plane wings level and maintain heading at a certain horizontal distance from the land point. This is allegedly somewhat helpful for a wheeled airplane so that it's not landing with a wing low, or in a crab. The issue with this is that the plane can get blown off course laterally due to it forcing the heading and limiting roll of the aircraft, as well causing this bug to occur.

What setting it to 0 does is allow the plane to follow the "waypoint track" up to and past the land waypoint with full yaw and pitch control, greatly improving lateral landing accuracy. We use belly landing aircraft, so the wing low or crab landing does not affect us on landing.

[1Gump]

@1Gump heading hold originally existed to force the plane wings level and maintain heading at a certain horizontal distance from the land point. This is allegedly somewhat helpful for a wheeled airplane so that it's not landing with a wing low, or in a crab. The issue with this is that the plane can get blown off course laterally due to it forcing the heading and limiting roll of the aircraft, as well causing this bug to occur. What setting it to 0 does is allow the plane to follow the "waypoint track" up to and past the land waypoint with full yaw and pitch control, greatly improving lateral landing accuracy. We use belly landing aircraft, so the wing low or crab landing does not affect us on landing.

! that's exactly opposite of what I expected HH to do. "Heading" invokes a thought of direction, not attitude. I thought the gyro/accel would normally be working to stabilize the attitude of the plane to prevent dropping a wing. Crabbing, though, does make sense in a directional heading hold with crosswind situation. Interpreting "heading" as the airframe fuselage pointed direction, I could see how this would cause a drift off course. i have certainly had trouble with the plane staying the course in a straight line, as you mentioned lateral landing accuracy, especially in crosswinds. i DID notice, however, the plane correct for a crab before touchdown (which was a pleasant surprise). i'm certainly curious now (uh oh). With larger, faster planes, a crab landing is much more consquential to the gear...dang i hate tradeoffs.

[Antiheavy]

"Heading" invokes a thought of direction, not attitude

In the aircraft world heading typically refers to the direction the nose is pointed (sometimes people call yaw and heading equal to eachother, but this sort of depends on what coordinate system you are referring to). this web page has a decent description about what "heading" means in the aircraft sense: http://www.chrobotics.com/library/heading-course-and-crab-angle

[1Gump]

thx a bunch @Antiheavy. good and helpful lesson.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.