Fixed wing auto-landing brainstorm

#1

I thought it would be interesting to see people’s ideas about fixed wing auto-landing, how it could be made better than it currently is in PX4, and other ideas, practical or wild, that might contribute to improved fixed wing autolanding in PX4. PX4 Discuss seems good place for general discussion and sharing of ideas.

This picks up on an old github post by @ryanjAA https://github.com/PX4/Firmware/issues/9778

Ideas may include:

  • improved use of laser range fingers (some people call “lidar”)
  • ground effect detection or estimation and control
  • 2-stage final approach with 2 different speed settings and glide slopes
  • modulate flaps/spoilers to aid in glide slope control
  • reverse thrust for glide slope control
  • improved baro compensation for fuselage and throttle pressure effects
  • use other sources of accurate height estimation, e.g. RTK GPS
  • improved deep stall support (might be related to flare code)
  • improved flare

FYI @ryanjAA @Kjkinney @M_Skelton @almaaro @tstastny @philipoe and anyone else interested in fixed wing landings

All ideas or discussion is welcome.

#3

I hit enter too soon before.

Thanks @Antiheavy. Good idea and here are some rough thoughts, some new, some old but here for discussion.

There are definitely many ways to approach this and there won’t be one right solution but anything is a start and I think overall we are simply missing some of the basics here. From countless observations (logs around if need be and on multiple aircraft types), i’ve seen a few glaring things missing.

  • Landing speed currently can’t be below min speed or tecs stall speed code kicks in (if we have flaps out, we should expect the landing speed to possibly be less than the “standard” min speed).

• Takeaway - we need a special landing min speed that is only observed during the final aspects of the flight (likely only on-slope, not during the new loiter to alt with flaps deployed functionality).

  • The ability to weight range finder usage on landing (if we have at our disposal adequate range laser range-finders, we should rely on them if the user chooses to, there should be a failsafe but it seems now there is an over complication of fusing all terrain data when we often see terrain alt estimation off slightly (couple meters, etc) which is huge during landing but during the last 15 seconds of flight or so the laser-alts are 99% of the time spot on to within <10cm. So why are we overcomplicating things? The option should be there. It would help with providing precise height data which is half the problem (see below).

  • Pitch PID control - we’ve looked at this a lot - when planes are slowing down (we’ve tested this on multiple planes), the aerodynamic authority is not the same for pitch control. Jet-ski effect. When we are landing the ability to nose up is reduced so going from negatvie 4-6° down to a minimum of +1° nose up at the last 2-3 seconds of flight (flare alt dependent), is not generally done with great precision. We took a foam plane the other day that flies great and had to set the min flare pitch to +10deg to get it to flare at +1 but the remainder of the flight was all correct… So increasing pitch control PID would help but then that effects everything else…

• Take away - specific or higher gains only used when landing. We could tune the entire aircraft to be more responsive but that seems incorrect given that if users are happy with overall control and efficiency of that control, why would we adjust everything to satisfy one (albeit crucial) aspect of the flight. Other option is a true nose up descent (see below).

  • Ground effect detection is a great one, it exists so we need to take it into account and always (approximately) occurs at 1/2 the wingspan of the plane vertically. So we should know that since that’s fixed for every airframe and not something that changes with alternate dynamics, etc. We need a way to handle that - parameter = ground effect height

  • Modulating flaps & spoilers - i like it but i find that will be hard. Mainly because flap deployment always causes a sudden change in pitch which is easier to manage at higher altitude. If it was a given change then we could counter it with the elevator but it’s highly dependent on the plane and speed. Anytime we start dynamically changing the airfoil I find it might be troublesome for everyone but the expert user and also only in situation where there is no change in airspeed (ie if it’s really windy all bets are off if we are messing with the flaps in and out not controlled by the user or to a static state).

  • Reverse thrust we be good, great actually but while I think while we should to do that, there are fundamentals that are lacking first. If someone wants to take a stab at it, we’ll happily test it but if the end result is a scenario where we cant pitch enough, terrain height is still off, etc, then it will not matter that we might have a great glide slope but to what altitude are we going to… I am all for reverse thrust, I don’t want to come off like I’m not I just think there are some basics currently missing.

  • Improved compensation for baro changes and throttle - definitely good one. Less of a problem then mainstream but it should be something implemented. Our planes in South America taking off at 8000 feet definitely operate differently (as expected) than the 0-2000 ft operating AMSL.

Overall - (and from what I wrote before), the top reasons auto-landing doesn’t work well is speed (maintaining the correct landing speed), ground detection and (actually) flaring.

Ground detection is discussed above but using a lidar is a quick solution (yes that’s overly simplistic as altitude estimates are fused but the terrain estimator is too complicated).

Speed is the second issue. Too much speed messes with landings because your flare all of a sudden is now actually a slight takeoff, altitude gaining event so we need to manage speed and actually decrease speed while we descend (shallower approach, reverse thrust, anything to bleed speed).

The flare itself - We need to be able to still descend with nose up at the final aspects of landing. So how do we do this? That’s something we need to accomplish (see below)

(Side note about flare we should have a flare failsafe that simply looks at alt above ground and the actual current sink rate and no matter what flares at X seconds to impact. Just in case all else fails.)

I think it’s really important to understand flare and how it operates for aircraft. It isn’t a preset numerical value and having that as the only option is a huge problem. On approach we should be slowing while descending and when we are in ground effect we absolutely have increased performance capabilities (compression lift underneath the plane) so we need a gradual and steady approach to reduce speed until we’re over the beginning of the landing location. That’s when we should be cutting throttle and increase our nose up while “floating” in ground effect. We’ll bleed speed and lose lift. The wing will stall as the landing gear touches if we do this correctly and we’ll keep the nose off the ground until the tail no longer has the aerodynamic authority to keep it in the air. Then we’ll have no bounce and not be able to fly (i.e. go back up). I mentioned this previously but we have footage of this during testing.

As @Antiheavy noted, a two stage approach would be ideal since flare is not a one step maneuver, it is a gradual and progressive increase in angle of attack. A balance between lift and airspeed, all while trying to time and calculate your impact with the ground. If it is looked at as a simple 5 degree sudden pitch change, it will be impossible to have smooth landings which is evident by most people doing so now. You can hack the current implementation to work (we have) but there so much to be desired (and no reason it’s not there). After all, landing is quite literally the most dangerous part of the flight and arguably the most complex (if by nothing else than it’s the one thing that hasn’t been mastered here in the code base or other pixhawk based codesbases).

I would think we do testing where we utilize the lidar (or altitude estimate) to an incredibly low altitude off the ground and tell the autopilot to command an increasing angle of attack as the aircraft slows until it eventually stalls and sticks the landing.

Lastly, upon contact with the ground we can do 3 things that will help it not bounce or pick back up.

• Elevator neutral (always)
• Retract flaps immediately (dumping lift).
• If possible, reverse the motor

Let’s take it from here and I know some is repeated and it by no means addresses everything in the initial post but we will happily devote a flight testing team just for this on a daily basis to get this right if we can get a consensus and some change to try and improve landing.

#4

I’m not a coder but let me know if input from a former single-engine flight instructor is welcome and I’d gladly contribute.

Good luck.

#5

My experience, it is very time consuming to determine the optimal settings for landing speed, flaps, airbrakes and possibly butterfly.
PX4 has an excellent logging system that can help us to do this.
My suggestion is that we introduce a remote switch where we create a new log file in px4 for each attempt to fly a landing approach. This allows us to fly a number of landing approaches in manual flying mode. For each approach a separate log file is available. These relatively small files can be evaluated so much more comfortably and above all more efficiently.
Jakob

#6

It’s definitely welcome! We spent time getting input from our aero guys and full-scale pilots (albeit not instructors) to articulate the ideal landing scenarios to be able to understand what we want from an autonomous landing so anything you can provide would be great. The simple descent angle and single flare at X is not robust enough given all the sensors we have on board and potential capability we have. An improvement is great desired.

We did this tuft testing back in 2014 to show when landing, how the wing should stall right as we landed. This was flown in manual mode with no stabilization, by a full-scale pilot. Not even a Pixhawk onboard but the idea being that we should look at how the optimal landing should occur and then go from there. Crow didn’t even exist yet on any of the flight stacks we were testing.

#7

I can understand the convieneince of the segregated landing log file but that might make it difficult on the actual logging function when in fact it’s not that difficult to just look at the final parts of the log.

My aim would be to devote resources to adding functionality to improve the actual landing aspect of the landing in lieu of additional resources on the assessment of landing unless people really feel there would be a benefit from segregated logs.

Landing speeds, flaps, etc are definitely all part of the testing needs to tune an aircraft but I think if we break it down even further there are fundamentals that are simply missing (I just opened a feature request for a landing airspeed that can be below the TECS min speed) since with flaps we should be able to fly below min speed on descent.

#8

Thank you. Hopefully I can contribute, in my small way.

I actually view it as a 3-stage process since that’s pretty much how I taught it in primary training.

  • Approach/ Descent
  • Straight and level flight at MCA (minimum controllable airspeed)
  • Flare/ Touchdown

[quote=“ryanjAA, post:3, topic:9837”]
Too much speed messes with landings because your flare all of a sudden is now actually a slight takeoff[/quote]

As a rule of thumb, approach speed is 1.3 Vso (stall speed) but maybe you could get away with 1.2 since the power-to-weight ratio is a lot higher for sUAS. For the purpose of discussion, let’s say the stall airspeed is 50 mph, so target approach speed is 65 mph. Standard approach angle is 3 degrees; steeper if there’s obstacle that needs to be cleared. There are two conventions of thought on how to maintain airspeed and maintain your glidepath as you descend.

  • One way, (I think the Navy teaches it this way) is setting up the pitch attitude to attain desired airspeed then use the throttle to control glidepath/ descent rate. So the basic procedure would be pull back on the throttle until the approach speed is achieved and adjust pitch and trim to maintain the airspeed. Use the throttle to increase or decrease your altitude/descent rate to target, i.e. if you’re above the glidepath, reduce throttle or if below, increase throttle. Watch a carrier landing on YouTube and this will verify.

  • The other, (I think the Air Force teaches this method) is pull back throttle to a predetermined RPM setting, maintain altitude until desired approach airspeed is achieved and trim. Use pitch to control glidepath, i.e. if you’re below the glidepath, pitch down and vice-versa pitch up if you’re above it.

Needless to say, in both usage, it doesn’t mean one or the other but in normal circumstances you can somewhat concentrate more on one or the other to lighten the workload.

For the purpose of sUAS and programming, maybe the first method might be “easier” to adapt? I’m thinking that with mostly electric powerplants, the initiation and reaction time would be more responsive? I’ll leave it to you experts.

During PPL primary training, every student goes through Stall Recognition and Recovery training. MCA is a major part of this. Learning how to fly with the aircraft “dirty”, i.e. full flaps and gear down, about 5 mph or less above stall speed. The stall warning horn is “chirping” and then make shallow turns without losing altitude. Minimum use of the aileron and judicious application of the rudder to prevent a stall.

This is the stage I consider and teach right before the flare. You know you’ll have the ground effect at approximately half the wingspan above the runway. So the approach/ descent must be arrested within the ground effect altitude and the aircraft is flown straight and level, albeit for just a second or two, maybe longer on a light wing-loading aircraft. This is also when throttle should be at full idle. Inevitably, the aircraft will start to lose ground effect and start descending (all happening very quickly).

Then the flare starts by continuously pitching up until touchdown. How much pitch up, visually I tell students to cover the end of the runway with the cowling. This is probably 5-10 degrees initially but the stick continuously pulls back as airspeed bleeds down, eventually to a point where the elevator can no longer hold it.

If everything went right, I agree with retracting the flaps but actually keeping up elevator contributes to aerodynamic braking. If the sUAS is equipped with brakes, this will actually make it more effective as the weight shifts more aft to keep it on the ground.

Hope all that makes sense.

Good luck.

#9

I appreciate all the insight. Seems spot on to me, methodical and something we need implemented.

There is a parameter already that lets you choose speed vs altitude (accuracy) as a preference but it is in no way representative of what you wrote to that depth (FW_T_SPDWEIGHT). You can set it to “adjust its pitch angle to maintain airspeed, ignoring changes in height”. So it’s very much lacking. Besides that and currently, pitch controls slope with throttle assisting to ensure you are “landing on slope” at the desired location but it is very much not robust enough. Arduplane does have further options that make it better adaptable (pre-flare, alternate speeds, etc) but switching flight stacks simply because one aspect is better covered or implemented on a completely different system isn’t ideal. Not yet at least for most.

Ok so as you said and parts of what i wrote before, we essentially need to trash the landing code and do something that mimics real-world. That needs to be the plan and if we want reliably operating systems (and this part of the system, landing) that everyone can use without countless hours of testing for each airframe (that’s how we ended up getting it working), then we need to implement this as above. There is no reasons this can’t work. It is just a matter of getting the code to replicate what we want and what we want should be based on how planes are actually landed.

#10

Here are some thoughts of mine regarding the flare.

In my experience, it has worked well to just define the flare curve by the position controller and then let the TECS fly along the path. Simple as that. At least this gets rid of any open-loop vertical speed control. This also means that the plane won’t be stalling at touchdown, but at least the landings are smooth. (I’ve never had a bouncy landing this way, apparently the TECS controller good enough at keeping the plane from climbing)

Stats of my test plane:
1,1m wingspan
700g
7m/s approach speed
Main landing gear behind CG
1m range sonar

#11

But have you ever gotten your plane to truly flare with a nose up landing?

I think the issue is mass as well even though that shouldn’t matter from the autopilot side. Overpowered setups on 700grams can change quickly what’s occurring than setups in 8-15kg range and I’ve tested numerous, well tuned planes, both foam and composite.

One thing I think that was touched on briefly but that doesn’t get enough real thought to is the actual aircraft efficiency or glide ratio. There is a huge difference from a flying pig and slowing that down is essentially just cutting throttle to something that is closer on the sailplane side of lift/drag and a very high glide ratio. The only way to truly remove energy with the latter is increased airbrake usage or anything that increases drag (px4 has but still are static in use), reverse thrust (px4 sort of has, not on fw yet) or a very shallow glide slope (present but often impractical).

Even the difference in 1.5 degrees in glideslope on something that is efficient is exceedingly more important than something that is has a high level of drag. The interesting thing is we should be able to write something that simulates a landing at high altitude (within the range of a long range lidar) to come up with the ideal and realistic parameters not close to ground.
Imagine a simulated landing at 30m, having it fly the plane down from say 60m alt and Xm away. That would give real numbers to if something is attainable, etc and we could do it above stall speed (as noted above) to show the landing profile much above the ground. That’s an interesting thought that’s leaps ahead of what you could do in simulation (just look at how simplistic [actually poorly inadequate]) the lift plugin was created for gazebo…)

Either way and back to what you were saying. The effect of change is highly dependent on airframe specific variables but also operational variables that are not going to be easy to model for the average user and the flare code reflects that any time there are challenges that may present themselves with the specific setup (which is the vast majority of users). You not having a bounced landing ever is truly a miracle. Same as having a pitch that is actually not below the pitch setpoint (which generally comes back to glideslope and speed) during touchdown.

#12

Sure, I bet that these kind of light foam planes are much more agile compared to the bigger ones, which makes them pretty easy to just “drive” to the ground.

Thanks for pointing that out. My plane is doing nose up landings every time, but that is also why I have not considered that some planes might need the stall/minimum airspeed to get the touchdown on the main wheels. So that is a good point for increasing the pitch until stall while flaring.

#13

Yes, my experience too on the foam side of things and that they are generally less aerodynamically efficient. Even on the heavier foam planes I find it hard to rationalize tuning the plane for ideal landings (more aggressive attitude control on pitch axis) when they are tuned appropriately for all other aspects of flight. You actually end up losing efficiency since you have to keep them borderline “twitchy”. Not ideal.

You’re lucky then to have nose up every time. How many degrees do you estimate it your nose up landing and with that what do you keep as min and max flare pitch? I’ve seen exaggerated situations where keeping the minimum flare pitch at 5 or 10 deg yields a plus 2 deg landing but that’s seriously a horrible idea increase in a different mission setup or wind scenario you actually do achieve +10. That’s a climbing situation (which you can limit by setting a higher altitude throttle cut during landing, again not great if in high wind though). Would love to see some video since I’ve been hard pressed to find anything out there except the videos we’ve made, of truly great autolandings on px4. Controlling the sink rate while maintaining nose up is ideal and tricky. That’s for sure and also wind play an important part.
There is definitely a lot that could be done on this.

Also, regarding stall speed, that’s part of the issue. As illustrated before, approach should be 1.3x stall but true landing can definitely vary and should be less. Especially with anything that’s creating more lift (flaps, slats, etc).

#14

I have NO experience with flight controllers, other than setting up a phack v5 in a plane at this time. I’m excited about it, and trying to dot-i’s and cross-t’s. I DO have experience flying RC planes manually and with basic stabilizers, and a little with a cheap RTH (GPS) system. BY FAR, the biggest concern I have with this autonomous idea is landing. gas-to-solid transition is SO unforgiving.
.
in my experience landing RC planes, as someone has already pointed out, different planes behave differently in landing. wing loading is key- higher wing loading = faster but more stable landing. so stall speed is a factor, but stall speed can vary a lot with flaps, and I LOVE to use them for landings - it shortens the landing space and reduces (most of the time) the likelihood of that dreadful stall wing drop over the runway (given no bounce).
.
also, sometimes 3-point landings are great. sometimes wheel landings (on the mains on a tail dragger) are great. 3-point landings, where the plane stalls to touchdown, is certainly a precise maneuver that requires precise HAGL knowledge, airspeed has to be bled off while flying, and landing occurs either at stall OR as the plane gently sinks with a nose-up attitude (i prefer the latter).
… wheel landing on the mains can be done at relatively fast airspeed and, sometimes, it appears the plane simply flies to the ground as its wheels contact. the wheel friction, then, acts as brake to slow the plane (instead of trying to bleed airspeed while flying). the wheel friction also tends to pull the plane forward to avoid bouncing. the “flare”, in this case, appears to be just enough to keep the plane from slamming the wheels into the ground, but does not include lengthy flight over the ground waiting for sink - it actually pushes the mains onto the ground WELL before stall speed. i like this kind of landing (though i don’t do it all the time because either is easy for me). its amazing how a plane can go from fast airspeed to landed using this method - much quicker than 3point landings.
.
that said, id hope that landing setup(s) allows for a variety of landing setups/planes. slowing down a big, heavy gas plane and keeping it in one piece on landing is different than a light-wing-loading electric plane (even though big gassers can be light WL too).
.
also, pls regard that cutting the engine at flare means that the control surfaces lose a lot of authority. i never stop the prop on landings - not unitl i get near the pits. this is ESPECIALLY important on windy days (most days are windy). SO, in otherwords, as the plane slows, you lose authority (i agree that gains should be adjustable to go higher at slow airspeeds) and as the prop slows you lose authority - right at the time where control must be precise. and gas engines do not rev up as quickly as electrics (sometimes they may even quit if firewalled immediately). so pls don’t make stopping the engine/prop at flare a hard-code.
.
a sensor (assuming lidar or radar?) for precise HAGL is mandatory for either landing, obviously. i don’t know (lack of FC experience) how often a lidar will be inaccurate (or how much), so i cant say anything about fusion ratios. that unknown is scaring me, too. i would be worried about relying on a single sensor for that reason, but it will eventually come down to that i guess. or a customized evaluation of a couple/few HAGL’s.

#15

Great discussion. It is interesting to see the concerns of users of wheeled landing planes vs belly land planes. I’ve always worked with belly landing planes and we typically don’t care what happens in the final meter as long as the nose isn’t about to dig into the dirt. We are much more concerned about hitting an exact spot on the ground and would gladly give up smooth flare, touchdown, and rollout performance for just slamming into the ground more accurately.

There is a new parameter FW_LND_THRTC_SC coming in PX4 1.9 (been in Master for a while). I haven’t tried it yet, but my hope is it will help us more aggressively maintain the glide slope the whole way down. Has anyone tried playing with this yet?

#16

Here are a couple of flares I’ve gotten.
https://vimeo.com/323256313

Things to note:

  • The video might include some flares that weren’t actually automatic (shouldn’t be there, 2-3 max). But at least the ones where the throttle stays at 10% for a longer time after touchdown are 100% sure autoflares (depends on when I have switched to stabilized mode).
  • The pitch at flare seems to be only a like 2-3 degrees, but the nose gear is short enough to make the front wheel be at an angle of 10 degrees or so. So it’s also a design aspect for the plane itself.
  • The throttle is cut to 10% 0,4m above the ground.
  • The ground effect seems to kick in at about 0,5m above the ground. This means that the plane will get above the flare slope, which will command a pitch down during the final flaring. This is not optimal; maybe the pitch could be clamped to not go any lower than it has previously been (after the throttle limit altitude) OR the flare slope could be adjusted to so that the plane will try to maintain altitude just above the ground, not aiming for the final altitude of 0m. Or at least ensuring that the code is written so that the final altitude is the same as the final altitude setpoint (then the plane will aim for the ground, not under it).
    (- Just to get the context, these landings use https://github.com/PX4/Firmware/pull/11099)

Here is another log view of a general flare than in the video:

#17

@1Gump Thanks for the insight! That’s always great and I think exactly the point of this brainstorm. HAGL is crucial in all this and honestly, when looking at lidar data on approach and just prior, it is rare that it is ever off. It’s always better than baro data (and GPS unless you’re using RTK but still, lidar sensors tend to be spot on so long as they are used within their useful range which is the important part) The lidar lite v3 is pretty reliable to 12m, sometimes up to 25m but thats even though it’s a 40m rated lidar. The lightware sf11/c, works great up to 70-90 pretty accurately). Those are generalizations and are highly dependent on the terrain but there are countless flights we’ve done so it’s fair to say that pretty much the case that we’ve experienced.

I don’t think hard-coding anything is a good idea and you’re right on windy days especially, forcing a throttle cut and your’e going to be lucky to get things to the ground remotely close to where you want them too.

Either of your approach are good, we just need to get something in the works that is much more expansive than current (and @almaaro has definitely been working on this).

Has anyone played with the early landing parameter (FW_LND_EARLYCFG). We’ve done a lot of testing on it and I had a strong view about keeping it as a parameter and not harding coding it as always the case as lower thrust planes with adjustable high drag setups (i.e. flaps down and ailerons up), could get in a tricky situation to maintain minimum speed even at full throttle so we took one of our foam test planes out in 18 mph winds and it didn’t crash but it barely made it through. I’m a big advocate of the work that went into it and function it provides though, I just think some disclaimer documentation is needed, especially on windy day and/or your specific plane setup. It is currently enabled by default which I think may not be ideal but we’re going to do some more flying with it (logs for those flights available if anyone wants to look).

@Antiheavy that makes sense. So long as not smacking the dirt, I’d probably be happy with it as well and focus on accuracy. Definitely pragmatic. I’ve seen some smooth landings in wind that are parallel to the landing strip that were fine because of the landing gear being used but I wouldn’t be happy if I was trying to hit my mark in those instances.

As for FW_LND_THRTC_SC, we tested it yesterday, it likely has a positive effect but I’m of two minds about it as we only have one data point so far (one log to base just that parameter changed as other params were changed right after) but, looking at just the data (it’s attached), we changed several other things significantly, including (and in tandem) with increasing FW_PR_P all the way up to 1 (from 0.08 as default) so it’s not perfectly definitive. That said, as was mentioned by @1Gump, keeping the throttle enabled but decreasing the time constant does seem to offer some good influence but there is still nothing definitive really. The aim of the testing wasn’t really for this otherwise doing so more methodically would have made more sense (i.e. altering one parameter at a time).

@almaaro Great to see! Thanks for providing those. Looking good. Also, your PR I’ve been eyeing for a long while. I’ve been wanting to get our guys testing it but our range finders have about a 100m useful range so I’d be curious as to how, or if at all needed, what to do to adapt your methodology for use, based on this (as opposed to for something with 1m). I don’t love the idea of send the plane close to the ground unless needed (i.e. landing), so that’s really only been the hesitation. Thoughts? I’m happy to get our flight testing team testing anything needed to improve landing all around so feel free to push ideas, etc and I can get things in the air as fast as needed.

I’m really actually torn between several things which we’ll keep exploring over the next couple of weeks which is landing throttle time constant (FW_LND_THRTC_SC), exaggerating the FW_PR_P (which from the looks of it, even at 1, didn’t negatively effect the flight of the plane but further analysis needs to be done for something conclusive) but did probably help the landing side of things, the range of flares given (min and max), flare altitude itself and lastly the throttle cut altitude. These are pretty important and part of me still thinks we can simulate a landing at 25m to give ant plane an ideal landing parameter setup. Thing of it as autotune for landing. It would deal with everything except ground effect…

One thing is for sure though, and this is starting to seem like a general consensus, we definitely need more aggressive landing PID settings in the absence of a multi-stage landing. The latter is much better (or maybe it’s not and both will always be needed), but the idea that with less authority due to less aerodynamic control is pretty plain to see and that we need more intense PID settings.

Really interested in @almaaro PR but want to make sure I understand how we go about testing this with a higher range lidar first as well as what the effect will be in all scenarios.

Last thing, we changed the glide slope angle by 1.5º and that made a huge difference, so with that said, decreasing this number becomes less and less practical but has a positive impact which also means that this would suggest if we (all) need to remove energy quickly, or, even better, in a useful manner, we probably do need to look at implementing reverse thrust. It shouldn’t be absolutely required but probably helpful, and not just for deep stall, but for overall use.

This image is from yesterday’s flight data:

If anyones, interested, here is the raw data:

https://review.px4.io/plot_app?log=bf946497-daab-483a-936f-da7f596f777d
https://review.px4.io/plot_app?log=ee2ebef4-eca5-4e0c-b090-28e8665c1768
https://review.px4.io/plot_app?log=3d09e8ea-19a1-443c-adcb-b455d85dc3e7
https://review.px4.io/plot_app?log=a0582667-e4a3-4dd1-a053-e8ccd6c28276
https://review.px4.io/plot_app?log=9336e1ea-eaec-448b-a239-1cbf4ad80e2a
https://review.px4.io/plot_app?log=89145392-abdf-4572-bce9-af1835396683
https://review.px4.io/plot_app?log=8bad85f8-b1d4-41bf-b962-fa77420ff5fd
https://review.px4.io/plot_app?log=1dc04884-6112-43eb-a801-f85c6c802c87
https://review.px4.io/plot_app?log=221aad68-456e-41cc-a496-652162ef8043
https://review.px4.io/plot_app?log=f7f58ed4-39da-4702-acdb-5bfe9da0bd07

@dagar FYI

#18

nice, ryan. i hope to understand what those parameters translate to one day soon.
.
one thing about aggressive pid/tc… it would be real nice to have this adaptive to airspeed, as a slower airspeed (even when just flying) tends to need/tolerate more aggressive control. is this already a feature? i dont know.
.
speaking of adaptive, it’d be nice to have a single program that can adapt it’s landing specs/method to the current conditions. ie, if its calm a nice slow, nose up floaty flare with full flaps might be chosen. whereas if the FC detects significant gusts, or crosswind to landing strip, it adjusts for a more “fly-in” type landing with less (or no) flaps, and maybe spoilerons. i cringe to think of this thing heading for the strip to autoland as a thermal appears - of course, that’ll be just after i say “ahhh, this ALWAYS works flawlessly, so im gonna put down the transmitter”.
.
the reverse thrust things sounds cool - if you have it. crow is a poor man’s reverse thrust ;^/ but that requires 2 aileron channels (some folks radios have maxed out channels) and, even then, some of those heavy WL planes seem to gain speed quickly, no matter what, with even a slight addition declination. gas engines (on a reasonable budget) have no reverse thrust.

#19

No problem, we should have another data set available tomorrow/thurs.

Regarding the params, just start with the definitions (https://dev.px4.io/en/advanced/parameter_reference.html) and then trial and error to see what they actually do in your specific setup. That’s the key but you’ll get there! Have to start somewhere and you’re on the right track.

One thing I can say is just stick with it. In the early early days, there were a lot of discouraging moments… Watched a flare occur at 60m (4 times in a row)… all kinds of crazy stuff. Flight code is much better now but still.

As for the aggressive PID based on airspeed, it isn’t currently scaled or based on airspeed but the system itself is quite robust. When you tune your plane to the flight envelope you’re operating at, it tends to do really well through it, it is just on the landing (i.e. really slow side of things that there is an issue).

I really like a landing alternative or “wind landing”, etc based on if wind threshold exceeds X or any logic. That would be great! I cant tell you how many time we have to show people multiple landing profiles based on if there is strong wind, etc. I have definitely seen gusts come when you’re 3ft from the ground and pick things up to mess with landing trajectory. Cross winds, even strong one tend to be handled pretty well. Just gusts but keeping a flat landing is the solution for that so landing profile would be great. We deploy flaps and spoilerons every time because we have a 30:1 glide ratio with a clean wing so anything we can do to add drag is a must…

Reverse thrust is cool, it’s tricky since there are a few different ways it’s done on the hardware side (channel range vs 2nd channel to control direction)… 2 channel ailerons shouldn’t be a problem if using a pixhawk since there should be no mixing done on your transmitter but completely with you on the whole thing.

A good take away: alternative landing profile based on wind.

#20

thx ryan.
30:1 wow… i can imagine waiting for that thing to sink over the runway (glances at watch). i guess that kind of airframe is necessary for flight endurance. do you use retracts? fixed gear adds drag (reduces flight endurance)… ive never done any r&d to determine which costs more: retract power or power to cope with fixed gear. i wonder.
.
the best belly-landers ive seen were jets. they dont have that exposed prop and i was amazed at how well a reinforced belly did on a smooth runway.
.
have you ever considered an adaptive lidar (range finder) sensitivity based on HAGL? i think i saw a setting for that? i was also watching a video on a lidar landing that showed a bumpy approach due to trees/shrubs in the pattern, and started wondering if the distace sensor’s sensitivity (or the plane’s reaction to changes) could be set to increase as the measured distance reduced (got closer to ground).

#21

I think it would be good to establish the frames for this autolanding improvement project - at least for the hardware side that we can expect the average user to have - and continue with that since the approach logic will be different for low range sonars and high range lidars.

  • Lidars: A 10m range lidar will probably fit to the average user’s price&weight&power budget
    (- Sonars: low range, but smaller price&weight&power consumption.)

This topic is already pretty complicated, but in my opinion the biggest challenge is to estimate the HAGL before a valid range finder reading. Ardupilot, for example, uses an iterative process: the plane will go around if the plane is too high above the ground at rangefinder activation (either because of barometer drift or the ground altitude changing). At the same time, the barometer is adjusted to the new ground altitude, giving a more precise estimate of the HAGL for the next approach. “Real” airplanes use an adjustable QNH. High-range sonars are of course not so sensitive to the barometer drift, which speaks for their selection as the default requirement for reliable autoland functionality.

Edit: In addition, the rangefinder reading is not taken into account before the LAND waypoint is active -> no matter how high the sonar range is if the last waypoint before turning into final is only eg. 2m above the ground.