@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: