In a future update is there anyway we could be able to do multiple closed loop flight plans? For example I should be able to send one closed loop flight plan and be able to send a whole separate closed loop flight plan somewhere else. Also a auto generated Landing plan would also be another GREAT feature to have so the land plans are consistent per aircraft that you fly.
What does everyone think about this? Personally I feel it would make flight planning so much easier than having a big list of waypoints. Also a auto generated landing plan would keep things standardized for that particular aircraft.
Landing only requires a waypoint with LAND command so there is nothing complicated as mission planning.
I think that in practice, a landing is often a little more complicated than just setting a waypoint and LAND. It’s what leads up to that point which is often key to a successful landing ie the approach in terms of direction, descent rate and altitude from the previous way points.
I agree! A good landing starts with a good traffic pattern. Even when I fly manned aircraft if I dont make a good traffic pattern, my landing is not going to be the greatest! lol… You might can get by with whats there now with a foamy, but bigger aircraft need a traffic pattern in order to make a great landing every time for every user. The idea is to standardize the landing plan per aircraft in order to make it even easier for your typical user.
I think that the ~3 stages of flight should be fundamentally separated - TAKEOFF, AUTO, and LAND.
With the current singular mission upload, all stages are combined, and it’s coming at a cost. For each and every mission, everything must be regenerated – in most cases from from scratch. If a mission is not finished due to any problem (battery/fuel constraints, payload issues, etc.), then an entirely new mission must be loaded or some workaround for a mission resume must be put in place. There’s already “workarounds” to go back to the middle of a mission when a RTL-autoland is unintentionally triggered. They are just that – workarounds. Once you land and need to do another takeoff, you have to restart the entire mission or regenerate/upload an updated one.
Considering that users already view the takeoff and landing sequences as fundamentally different from the mission portion of the flight, I think they should also be able to be separated on the autopilot end.
I would argue that a significant portion of the community using auto mode also use the grid feature for remote sensing. As we make our vehicles smarter and able to make better decisions than us, multiple pre-uploaded missions make sense. Our planes can decide to scan another field, conduct another flight line, or go land and finish the job later. Separating the mission and allowing multiple missions would allow for landing, takeoff, and moving on to the next mission without any recreation or re-uploading of missions.
I have heard this brought up my numerous users recently. I think it’s time to find someone to get it done. I volunteer my help, but I can only do so much.
@hangarspace
@garlandk
It is obvious that you must know what your plane can perform and what it cannot for the descent rate as well as speed but once you know it it is just actually a matter of where to put the Land waypoint.
A real plane is a completely different stuff because the autopilot of a real plane have fortunately much better landing strategies than Arduplane has today.
I have past the last 5 months working landing strategies using Arduplane and a 3kg plane with airspeed, reverse, Lidar .
The actual Arduplane LAND mode do not use all the plane capabilities, I can land manually , much better than Arduplane, this should not be since I’m a bad pilot.
There are several bugs in LAND mode that basically works well only using LAND_FLARE_SEC , so a kind of water landing that do not need airspeed or range finder but a lot of space to land.
@Naterater
I would like that TAKEOFF would be not part of a mission but a flying mode used just to put the plane in the air .
The other thing that should be add to Arduplane are some escape strategies in case of bird attack during a mission.
Arduplane has the capability to make a better landing than an average manual pilot. I have done plenty of testing to prove this.
In order to make it easier, having a pre-set land plan would make it easier for the user to create a landing plan and involves no guessing for your average user.
A real aircraft flies the same as a unmanned aircraft for the most part. You need to have a great traffic pattern in order to have a successful landing. A traffic pattern will help set up the aircraft to make a successful landing. Today with arduplane I set my landing plans to look like a traffic pattern. It makes for a cleaner approach and landing. Why not have arduplane auto build this traffic pattern?
I think before we setup the above we need to focus first to be able to have multiple closed loop flight plans. This would make flight planning A LOT easier.
I do not agree with you and I have done hundreds of test landings in the last months about capability of Arduplane landings , try to make a short landing and you will see.
About planning the landing , setting several waypoints before Land waypoint as an approach path is not recommended by Arduplane developers.
Removing the argument about who can land better, there are numerous other valid reasons to support multiple closed loop mission flight plans.
Looks pretty good to me considering the wind and bumpy Arizona air and being a inverted V Tail aircraft. Also this was flown using multiple waypoints for landing. It works…
This is another fun one to watch. Big thanks to Tom for giving me a build that does Auto Touch N Go. This is needed for adjusting gains for auto landings. Basically after the take off it goes around the pattern and makes another landing and keeps doing it. I always make my changes on the upwind and downwind.
Nice, your video confirm what I wrote , if you have a lot of space and clear approach Autoland works fine.
Try to land with 25 meters trees around and 60 meters landing runway and you will discover all Arduplane Autoland limits.
Why not? How would you even roughly align with a runway direction without having a waypoint on the extended runway center line?
I wrote “several” and I meant setting an approach path with different waypoints and altitudes.
Several altitudes would mean several TECS calculations that could use or not a slope depending on the delta of each altitude.
It’s funny you mention that the whole point of this request is to be able to have pre defined landing pattern when certain settings at each stage. It would help everything you have mentioned…
Please post any logs or video of your landings so we can see what problems you are having. Would love to see video for sure.
As far as several points on the current landing pattern… I don’t have points on final approach. You need points leading up to the final approach in order to align with the runway. There has been nothing wrong with doing that.
I think that one is required 
Here’s what Tom said earlier this year at the unconference on autoland:
Interesting video, not easy to fully understand for someone like me that not have English as native language, even the Youtube subtitles did not help much but were fun. 
What we would need for sure are some Wiki lines of explanation the procedure considering the 18 parameters in the 3.8.4 for those who want to dare with Deep Stall landing .
BTW , what is the purpose of DO_START_LAND in the spiral landing mission ?
Reading the Wiki it looks more related to RTL or different landing sequences available .
Totally agree, that lumping together mission and approach is an unfortunate compromise. Soon after starting with auto missions I already ended up with stored *.waypoints files, that had all the same mission but differed by the approach and the runway (direction). So I always had to load another mission, if just the wind direction changed.
As food for thought, let me quickly mention my system FlightZoomer, which sits as a “pilot convenience layer” on-top of Arduplane. The system emulates many ideas, principles and procedures of manned aviation.
The following principles are applied (entirely as done in full scale aviation):
- You define the airspace upfront (this is an office job)
- Relational navigation database
- Waypoints, airports, runways and approaches are reusable and separate entities
- A flightplan primarily contains references to waypoints
- The approach is picked on demand
- The relevant geometrical parameters for an approach are already defined in the navigation database: runway direction, touchdown point, glideslope angle, glideslope interception altitude
In the cockpit app you then can just create missions using predefined waypoints, runways, approaches. The active runway (depending on the actual wind) can be changed at any time. There is a inbuilt voice guidance, mimicking air traffic control, that gives basic vectoring instructions which can be followed by the pilot (even by automatically feeding them into the autopilot), in order to fly a proper approach pattern to the selected runway (downwind, base, final) followed by an autoland.
This video shows all steps from scratch, how a rudimentary navigation database is set up followed by a short flight (in simulation mode), that shows all the features:
More information on https://flightzoomer.com/