Plane: Auto Landing Pattern

[bchristal]

There needs to be a way to get APM Plane down without having to manually fly it. Sure you can setup a mission with descending waypoints and auto land, but this isn't always an option. The pilot needs to be able setup a landing approach and easily access it without having to program it. Consider the following:

1. Autopilot is armed, home/landing location is set.
2. An approach waypoint is also set 200 meters behind and 30 meters above home/landing location. The pilot just needs to be sure he aims the plane in the desired approach direction when he arms the plane. Typically into the wind, or crosswind, in front of a clear approach path. That will be the glide path.
3. The pilot can initiate auto land at anytime while the plane is in a guided mode by selecting auto land as a switch option or an on screen land button on the ground control station. Upon initiation of auto land the plane will fly to the approach waypoint. The plane will circle climb or descend until it reaches the proper approach waypoint altitude, then it will start its glide path down to the home/landing location.

Here's is how the Ruby handles it: http://www.uthere.com/products/ruby/documentation/operation/landing/landing_pattern.html

-Brian

[magicrub]

this sounds a bit dangerous.

[bchristal]

What's dangerous, that is more dangerous than trying to build an auto land flight plan yourself? I setup auto lands often. For starters, when you're in the field, looking at your laptop in the sun it's almost impossible to find the location on the map where you want the plane to land. Setting up a landing plan "underneath" a survey grid in the flight planner is also difficult. There are lines everywhere on the screen. I think one of the most dangerous things are inexperienced pilots trying to land planes manually. I know they shouldn't be there in the first place. But they are. They do it with DJI products, and they do it successfully with eBees. Iv'e seen it. Take a look at minute 1 on https://www.youtube.com/watch?v=oZ3ZSnQM7v4 and you can get a glimpse of eBee's auto land setup. I think this is one of the most needed features in ArduPlane. Can you imaging if ArduCopter RTL didn't support land? That is a necessary function of the autopilot. That flight plan is automatically generated on boot up. Thanks for listening!

Cheers,

-Brian

[EShamaev]

I am working on exact principle rewriting most of all landing code. Will be ready for test in few weeks.

[magicrub]

I look forward to it @EShamaev !

[EShamaev]

May I expect a support for adding needed functions to mission planner?

[EShamaev]

I am making real approach procedure working in auto mode but many settings need to be done. Is it better to put them in parameters or configure from a flight plan?

[magicrub]

Please post GCS requests to their respective issue tracking locations. For example: https://github.com/diydrones/MissionPlanner/issues

[magicrub]

@EShamaev it depends on what you're trying to do. I suggest putting highly-dynamic values, ones that are potentially different on every mission, into the mission cmd instead of params.

[EShamaev]

The values will be pretty much fixed for a given runway. But they are different from one runway to another. Does it consider highly-dynamic? The reason I am asking is that I am not sure how to put 5-6 parameters into mission cmd. But I got the idea and will think of separating them.

[magicrub]

What params are you thinking of?

On Mon, Jun 8, 2015 at 9:08 AM, Eugene Shamaev notifications@github.com wrote:

The values will be pretty much fixed for a given runway. But they are different from one runway to another. Does it consider highly-dynamic? The reason I am asking is that I am not sure how to put 5-6 parameters into mission cmd. But I got the idea and will think of separating them.

— Reply to this email directly or view it on GitHub https://github.com/diydrones/ardupilot/issues/2303#issuecomment-110056043 .

[EShamaev]

Basically these are 3 groups for my application:

• Approach type: loiter, S-type, racetrack, hockey, etc. and theirs parameters
• Altitude parameters
• Distance parameters

I though of using special "modification commands" before auto_land cmd. If such command is issued it will override the default parameters. So at max there can be 3 more "modifiers" issued before the land param. In these commands I will use all available fields for data transmit.

If no modifications are made then let's say loiter type with predefined altitude and distances will be used. Like in Ruby example.

These parameters are not related to plane parameters but set the runway params, so I don't think it is good to put it in plane param tables.

Does this way sound right?

[EShamaev]

Issue Arduplane Helical Landing Pattern #2279 will also be solved in nice manner with landing procedure I design.

[Daniel-1276]

I like the idea using auto_land without GCS, very neat :)

[jcooper21]

+1

[jcooper21]

[magicrub]

I get it I get it, everyone wants this!

[jwahono]

I do really want this feature.

[magicrub]

helical turn landings work muuuch better now that we have LAND_SLOPE_RCALC

[Sulter]

I've found that wind is a big problem with auto-landing too. Especially with 30min+ flights, the wind direction might change a lot. So now that we are looking at the features of the ebee, and trying to improve the landing pattern - why not make it automatically land into the wind, instead of "just" the same direction as it was launched? I've done some testing (so far only SITL) and the wind speed+direction calculation done in Mission Planner seem to work very well: https://github.com/ArduPilot/MissionPlanner/blob/5cbdeeac9d4b6fb725f7454ae0739b2c60db5e61/CurrentState.cs#L2172

I'll come back with updates after some testing with a companion computer calculating the wind, and re-arranging the last waypoint before land accordingly.

[magicrub]

Wind is always calculated within the aircraft. I already have a PR for land mission change depending on wind but Tridge did not like the mission changing. We have ideas how to do it better, I'll look up the pr soon and cross post it when I get to a computer. The answer is definitely not to have mission planner handle it

[Sulter]

I wasn't able to find the PR, but I'm looking forward to seeing what you got.

If mission changing is out of the question, what about this: new CMD (MAV_CMD_NAV_LAND_AREA?) Mission Param 1: Abort Alt Mission Param 2: radius of approach aka. land area Mission Param 3: approach altitude Mission Param 4: empty Mission Param 5: Latitude (of desired touchdown spot/center) Mission Param 6: Longitude (of desired touchdown spot/center) Mission Param 7: Altitude (of desired touchdown spot/center)

The landing would work as the normal one. Except you wouldn't place a approach waypoint as you usually do, instead the ardupilot will pick a spot in the outer ring (at approach altitude, radius away from the center) depending on the wind direction and just land at the center. This would obviously not be intended for runway landings.

I would be more than happy to contribute with code and/or testing if a feature like this or similar was to be developed.

[magicrub]

Turns out I only posted the mavlink PR https://github.com/mavlink/mavlink/pull/579 which describes what I've been flying for 1.5 years but it is not a generic solution. The offset part makes it complicated. Example: if you change the mission then when you reboot the mission is different than the last time you rebooted! For me my companion computer writes the mission before we arm so I never considered that, but not a generic solution. @tridge and I discussed this and we think we'd like to have them auto-generated in flight with a magical waypoint item. A new NAV_LAND type command would describe what kind of landing you want then it would generate it and do it. Examples: land into wind, helical landing.. ect.

[snieves0014]

Good day gents. I was wondering if there is anything moving forward with the auto landing setting? This would be invaluable!

[magicrub]

no movement so far, sorry! We're all pretty busy with various things and somehow this keeps getting delayed. Pull requests welcome! Also, discussions on what the PR should be are welcome too :)

[EShamaev]

Finally!

@tridge and I discussed this and we think we'd like to have them auto-generated in flight with a magical waypoint item.

I proposed that more than a year ago and Tridge was telling that it's too dangerous... I am ready to switch in this

[magicrub]

Fyi, there has been lots of progress piece by piece to abstract out a bunch of plane code into a new AP_LANDING library to make this possible.

[EShamaev]

I saw that in code recently. Is there a defined roadmap?

[magicrub]

For a feature that I recently added for tridge, I intentionally broke up the functions so that we could reuse the same ones as into wind helper functions.

https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_Landing/AP_Landing.cpp#L261

Ardupilot does not have any official roadmap, but we discuss ongoing and proposed work at the weekly Dev call on mumble. I encourage you both to attend!

On Dec 18, 2016 6:42 AM, "Eugene Shamaev" notifications@github.com wrote:

I saw that in code recently. Is there a defined roadmap?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ArduPilot/ardupilot/issues/2303#issuecomment-267804710, or mute the thread https://github.com/notifications/unsubscribe-auth/AEj7G7q91KYbFFeuGjyiDkejoZJTzOamks5rJMfBgaJpZM4EdtHV .

[fredrikfalkman]

Hej all! Reading this discussion with great interest. I'm working on project where we hope to be able to fly BLOS eventually. Just got our own restricted airspace set up to do it in for testing! For BLOS flights RTL as a failsafe (i.e. due to a comms loss) would be dangerous since the plane would essentially fly blindly for an extended time and distance. One natural way would be to pop a chute but a chute adds weight and may be problematic in windy conditions, but a helical or into-the-wind failsafe autolanding would also be a good solution I think. Provided I haven't missed this functionality if it already exists, what are your collective thoughts on this? Thanks!

[moreba1]

helical landing isn't a suitable method , Because the radius of turn is high and wind speed is an obstacle to this. Also, to determine the direction of the landing on a one-hour flight, it is necessary that the starting point of the landing in the flight is changed, but the mission will not be performed again from the first.

[Avalonnw]

Sorry for reviving this, but it seems extremely useful feature to pass by :) What would be a nice solution IMHO is the ability to create a second custom landing mission which would be independent of the main AUTO one. I'm not sure about stats, but it feels to me people generally have an idea on where exactly they are flying or will be flying, so they could (theoretically) determine approach and landing strip well ahead of time. If it could take wind direction in consideration, that would be awesome! So, if a pilot could define, let's say, 3 objects: a runway and two safe-to-descent areas (one on each end for example), so whenever Landing is triggered (be it from switch of from mission) the plane would decide which direction of landing it should use based on wind direction, follow to a corresponding safe descent area, descent and land.

[magicrub]

About a year ago @wickedshell and I refectored the whole landing scheme to put it into a new AP_Landing library. The idea was to allow a flexible landing selection. That's when we added deep stall as an option. So, the infrastructure is there now

[kikislater]

Deep stall seems cool but nobody except devs know how it works ! How to learn how it works ? In final stage @ 10m AGL it could be nice for flying wings, using SITL ?

[Avalonnw]

I was actually wondering about deep stalls. To me (and that's my personal opinion, mind you) that's about as useful as having a brick on a plane. I mean, the forces on the plane during the landing like that are not far from your generic old-school crash-landing by the looks of it. Why would you want it, if you crash plane regardless? Would not it be better to recover from stall and actually land, nicely and softly?

[kikislater]

These are deep stall and soft except for cumulus and Lynx : https://youtu.be/AXSY2MVRXbE?t=1m https://youtu.be/ctCh9kX5cUU?t=20s https://youtu.be/AXSY2MVRXbE?t=1m https://www.youtube.com/watch?v=G4mYmm5z2Zk

I have an FX61 ready to crash with reverse thrust enable. If some want some test but need a little documentation ! Just found it today : https://www.youtube.com/watch?v=XuSl9Io93aQ&index=2&list=PLS2ntMaPm2ZUQAyrXMFEuVUW95Az9Xfhy

[magicrub]

@kikislater have you looked at the auto landing wiki yet? It explains reverse thrust.

[kikislater]

Hi @magicrub , No need to get explanation about reverse, I've got success with it thank you : https://discuss.ardupilot.org/t/auto-takeoff-and-reverse-thrust-not-working-after-upgrading-from-3-7-to-3-8/20262/8

Just need explanation about deep stall !

[magicrub]

Ping @wickedshell

[Naterater]

It appears to me that this issue has been solved with the implementation of LAND parameters and mission items. A lot of awesome work by multiple developers has gone into this. From here, the comments appear to be documentation requests, etc. If there are specific feature requests or issues, I believe they should be searched for or created as new issues.

Does anyone still want this issue open?

[WickedShell]

Auto land pattern involves selecting a lot more then is currently allowed (except for deepstall, or quadplane) and this should be left open for them.

[Naterater]

As it stands, Ardupilot now has an automatic landing feature that fulfills this request.

I think the advanced features of doing something such as intelligently choosing a land approach should be brought up as a separate issue/feature request on a clean thread. This issue is muddy enough and will go on indefinitely with its broad title.

[kikislater]

If you think so, let's us do a proper documentation together ! But proper auto landing pattern doesn't rely only on firmware but also with proper ground control (qgoundcontrol have a proper GUI interface to do it)