i have a tfmini (10m lidar) but im afraid to use it since i heard mention on a forum that: 1) 10m is too low to initiate a landing sequence and; 2) 10m outside over not-so-ideal reflective surface is optimistic - probably more like 3-5m. id love to be able to make a low-cost tfmini workā¦can i?
ā¦so im thinking, even at 10m AGL, there is good opportunity for trees/shrubs/towers/poles/wires, which increases the collision risk of ācalibratingā HAGL fusion down there. Ardupilotās reported operation (@alaarmo) might be fooled if there are trees/shrubs in the immediate approach path (since it calibrates only after land wp). iād think a periodic calibration (before land wp) would be more ideal, and preferably over known āsmooth-ishā terrain? but, even then, 3-10m might be a bit risky. some missions getting that low before landing would be impractical. to avoid this, ardupilot would need to have the land wp in a known smooth-terrain approach path, not more than 10m (probably less for tfmini) agl. that seems awfully close to touchdown? im thinking most of these missions result in at least 1 go-around (more if cal is harder). if thatās true, id recommend finding a way to avoid/minimize go-arounds - iāve seen lots of electric planes coming in barely able to stay airborne with only 1 try before power system shutdown.
.
i am scratching my head about determining HAGL before a valid RF reading (@alaarmo). loading maps with precise elevation@gps coords and calibrating baro perodically might work? is that feasible at this point in time for a hobbyist with pixhawk/hack/clone? (maps are used in larger ventures). Would an offboard map solution be preferable to a lidar solution?
So should we differentiate by size, use-case, glide-ratio, weight, lidar range, ā¦?
Yes. It did take awhile to get landing how we wanted to. We actually ended up using the PX4 codebase because we were able to get the crow setup written and implemented for us back in 2014 and it wasnāt available on other flight stacks. Retracts are more of an issue of where you implement them into your airframe than power to utilize them. Our record to date is cruising below 100 watts although that was a tailored test. Still yes, all this necessary for really long electric endurance without the use of hydrogen, solar, etc.
There is some code about quasi-adaptive lidar in a sense but not exactly as you describe. Mainly because the drivers for each lidar are set to a specific range and some of the lidar models can be set to output a range outside of the drivers expected range if pricing invalid data so it is not taken into account in the terrain estimator. I find that terrain estimation, albeit in my view is a bit overly complex, is not the main issue. Itās the process in which the flare is executed. Knowing the true distance to the ground is relatively consistent. We do have teo regularly used test sites that have a tree line before the landing strip in one direction and that does cause a spike in lidar altitude one clearing it but the offset is never too bad. It records quickly enough. It could definitely be improved from a codebase side but again, I see the implementation of flare as the predominant issue.
The planeās distance to the ground and an increases reaction to changes required is partially what weāve been taking about in regards to increased or exagerated PID settings for the landing portion of the flight because the system needs more authority right ten. .
@almaaro a things about this. I would say the average lidar range for the a user is 40m with an effective range around 30m. 10m isnāt realistic for a fixed wing plane and the cost has rapidly decreased for 40m units. There is no point is trying to make something work when it should be done correctly with different hardware that suits the task which is what you are saying. I just mean I donāt imagine a safe and reliable scenario where you try and rely on any autonomous landing using just a lidar with a max range of 10m and effective range of 3-6m. We shouldnāt be trying to cater to that since thatās not what people should be using if they want reliable and accurate landings. Longer range units are simply more practical and safe. Splitting this into two use scenarios where you have a split group and also cater to short-range range detection units is fine but that will more and more become a minority since things like sonar suffer from so many other issues.
The iterative process is methodical, so long as we are not too close to the ground and we donāt have obstacles in the way. That said, we can use terrain estimation or some variant to get an idea of agl prior to range sensor data but that still needs to be tied to some point in the flight path to not cut off people who do simply have valid readings beforehand. Autocorrecting the bari is a great idea. @1Gump maps are much too inaccurate for landing so thatās a no go truly a quality range finder is the best and if we are worried able obstacles, trees, then fused data is a perfect fit.
Before even any differentiation occurs, that is essentially just tuning a framework in place. We need a framework for the landing portion of the flight that is representative of reality and will provide and give smooth flared landings. Thatās before anything else. Im interested in @almaaro PR but not until I can understand how to implement at a higher altitude.
Our aim should be to identify what we want on the landing portion of the code specifically and how and what we want the plane to respond to.
Iāll put some thought into it and put some points down but that should be our aim. I see more of an issue with how we land rather then the HAGL currently.
Also, we have more data from subsequent testing yesterday and today but it isnāt relevant since we were in 25+mph winds on the ground so it will skew any data. Weāll get some more on Monday.
Letās agree on what we want the landing to look like and then if there are certain PRs they can be added to further improve this than that would be great.
@ryanjAA Ok, sounds good. Just to make things clear, I propsed the 10m lidar because I didnāt know that 40m is the standard. And with that range the barometer/ground altitude offsets should not be an issue at all.
Anyways, one feature that I would find value-adding is that the waypointsā altitudes would be above HAGL already after the LAND_START waypoint or as soon as the lidar gets the reading.
@almaaro sounds good and makes sense. Regarding waypoints after the land start, do you mean dynamically adjusting them once the range finder has a valid reading? Not sure I understand 100%.
A few things we need to get in place are a multi-stage landing.
Preliminarily:
3 Stage Landing (thank you @rollys )
- Approach/ Descent
- Straight and level flight at MCA (minimum controllable airspeed)
- Flare/ Touchdown
With that:
-
we need the ability to fly below TECS min speed on approach only (useful for if flaps are deployed).
-
glide slope settable (as is currently there) but flying down to a specific altitude and airspeed
-
flare pitch (already there)
-
Fly on slope to MCA and then alter the slope so the plane is flying level, quasi heading hold related but expands to include only when at MCA and a specific altitude is reached.
-
Terrain Altitude adjustment - we should adjust terrain altitude estimate in a similar way to how your pr does it (from maybe a higher altitude or settable altitude though) taking into account the range finderās available range to give a truly accurate terrain alt and actual distance above the ground for the final landing part of the flight. land start waypoint etc.
-
Ground Effect. MCA should also take into account ground effect. We should account for this and have landing assume that if this is enabled, we will have more lift at 1/2 the wingspan of the specific plane. (Parameter) meaning it will be more difficult to get to the ground (are landing PIDs)
-
Flare and touchdown should then occur after this 1-2 second level flight via a min throttle setting (something that can be set arbitrarily what that is) and a nose up to lift the nose while dropping altitude due to throttle drop.
-
if we find this proves very long landings then we should maybe think about how to shift this whole process backwards in terms of the final landing point to achieve accurate poisition landing whilenachieving the above.
Also needed in general:
-
Landing PIDs. increased, exaggerated or landing specific PIDs for pitch only (not really needed for roll or yaw) but if someone has a reason to add roll or yaw, thatās fine.
-
option to set a manual flare based on time to impact given sinkrate (taken from Arduplane). Good option if we want to to ensure we are going to flare no matter what.
Any other thoughts and chime on in but so far that seems like it would cover the 3 stages of the landing.
@ryanjAA yes, dynamically adjusting the waypoint altitudes with a valid reading.
One more thought about the flare: If the flare is executed by flying level and cutting the throttle, then this is a trade-off with the accuracy of the landing. If there is a set touchdown point where the plane will aim at, it will be more accurate, but the landing speed will be probably higher. But since the plane will decelerate faster in the ground, the total landing distance would be less.
I donāt think you necessarily have to look at it as a tradeoff. Essentially, youāll have two targets; the aim point on the runway for your glidepath (the threshold) where you will arrest the descent by starting to fly straight and level. From the threshold, the aircraft will try to maintain altitude but since throttle is idle or off, the increase in pitch will slow it down as well as create the pitch attitude transition from straight and level to flare to touchdown. The touchdown point is beyond by āxā number of feet. Watch this short clip of what I described as seen from the cockpit.
[quote=āryanjAA, post:26, topic:9837ā]
Ground Effect. MCA should also take into account ground effect.[/quote]
Would it be more feasible to look at it as a flight profile instead trying to come up with some formula to estimate ground effect? Letās pick 10ft or 3m above the threshold, for starters, where the aircraft will chop throttle and level off. At this point, it should maintain heading, wings level and pitch to try to maintain altitude ala Position or Altitude Mode. It can accept diminishing altitude but not any increase. So, when it gets into ground effect, it should be adjusting pitch to just maintain it. As ground effect diminishes, then let it act like itās in Altitude Mode but sheāll eventually touchdown and speed goes down to zero.
Through flight testing, adjust the threshold altitude to get the desired touchdown distance in a no-wind scenario. That will be serve as your max distance to touchdown point. As the wind increases, then the touchdown distance will shorten.
Hope this invoked more thought process to approach the code side.
Agreed on the accuracy trade off not being too much an issue because as it is currently, the landing point you put is not the touchdown point. Thatās actually the flare point so itās already inherently innacurace. We just need to know what happens under this new scenario and then we probably can do as you said, know what the max amount of distance past the landing point the actual touchdown point will be in a no wind scenario. Thatās a good way to start since adding an estimate to actual to touchdown after that would be trivial.
As for ground effect, we can pick some number (a parameter) above the threshold (which can either be an altitude or wingspan - doesnāt matter all the same) but it actually is probably easier to set a per setup number rather than as a profile since griund effext tends to always occur for any plane at an altitude equal to 0.5x the wingspan of the plane. That makes it easy. Adjust the parameter from there is you need to.
As for the rest of that aspect of landing. It seems spot on. Keep everything level and watch alt decrease by pitch up to stick the landing. I think this all seems like a solid plan to make landing occur much better. Iāll write this up as some bullet points if we come to a consensus so we can finalize what probably should get done.
Great discussion.
.
I donāt know what that āfwā¦scā parameter was, so Iām gonna ask that this āthrottle cutā, whenever it is, be variable in regards to amount and rate. In other words, maybe I want to bring my throttle down to 12% over a 3 or 5 second time frame rather than immediately āchopā it to 12%.
.
Ideally, Iād want HAGL, airspeed, wing config and, to some extent, distance to landing point determining my throttle position. As I mentioned previously, I very seldom chop throttle or reduce to idle before touchdown. The only time I do this is on a steep descent on a calm day where the plane has plenty of airspeed (way above Vso) and I fly the mains into touchdown (donāt wait for sink). Honestly, chopping throttle on flare for RC planes seems to be what beginners do, and result in many landing mishaps/damage. It works if everything is done perfectly and conditions are perfect, but thatās seldom the case. FS AC have much more mass and momentum. Larger AC always seem much easier to land than smaller ones.
.
And, if I have achieved āMCAā before flare, I CERTAINLY will be using throttle to land - like @rollysā ānavyā example, like a pitch up 3 point landing ā¦ But I prefer throttle for altitude control not a timed stall in times like this, because the plane is usually too high to āstallā safely and is WAY more controllable with prop wash and a throttle contolled sink rate (pitch up, flaps down).
Anyways, Iāve found landing is way more successful if touchdown is done under (reduced) power and the rollout is where throttle is eventually reduced to idle. But I fly warbirds now, not sailplanes (any more).
.
So, can there be some sort of āautotuneā where the FC can determine glide ratio and sink rate vs throttle position vs airspeed (with adaptive pic/tc) vs wing config- in order to automate/approximate setups for autoland parameters? That way the FC can know how to set my wheels down easy, using pitch and throttle, based on airspeed and HAGL. Sailplanes would seldom see the FC turning the prop, whereas a heavy wing loading plane might see quite a bit of throttle.
.
btw, i fly mostly above 5kā ASL, Vso is a bit higher than sea level. Folks that visit always comment on how the planes fly and land differently 'up here (faster, less lift).
.
got me thinkingā¦could px4 calculate density altitude with various pixhawk/hack sensors and apply a multiplier to the autoland parameters for an adaptive (altitude/density) solution?
āfwā¦scā is referring to FW_LND_THRTC_SC which is the throttle time constant only for landing. Essentially this time constant is multiplied by the normal TECS throttle time constant (FW_T_THRO_CONST) to give faster TECS reactions at the landing phase of the flight. If you ever are wondering about what a parameter is, you can look it up either in the PX4 Parameter list here or the devguide PX4 Parameter list on github which while one pulls from the other, sometimes the github link works better here.
Also, pretty much anything that has to do with any type of setting will not be created in an on/off binary state. All parameters are generally added with numerical representation so as to tune your specific plane accordingly.
With regards to amount and rate, you want to be able to have a slew rate. Seems reasonable. Letās keep that noted for any type of throttle cut.
Noted on your points re determining throttle position during landing. Weāll need to create some examples of the workflow (that is, from the penultimate landing start waypoint to touch-down and see what makes most sense. Thatās likely the case we are at now. Then we can determine what makes sense for someone to implement.
While I have huge respect for the work that has gone into the landing and other aspects of flight to date, itās incredible all this data can be fused together and used for landing these things, I think we can agree there is a lot more that needs to be done to get this to a state that is reliable for all users and in various scenarios.
As for the landing āautotuneā, I donāt see why not but that will be best answered by whomever ends up putting this in place and also how much work it will take since it essentially is a replacement for human testing. That said, Iām actually for getting a FC created landing setup, it would be a big help for people that simply canāt or donāt have the experience in setting their setups correctly for landing (which is probably the least developed or robust part of the entire codebase.
Yes, a huge difference. Stalled props (high pitch) at high ASL can reek havoc on new pilots that donāt understand the decreased thrust created, etc. PX4 can already take altitude into account for throttle compensation so this would likely be the closest thing, FW_THR_ALT_SCL.
Time to start compiling the workflow of events and what happens when for this and letās see if all looks good from a processes perspective.
thx @ryanjAA.
ā¦ i feel like im grasping at shadows here since i dont have any real experience with good flight controllers and absolute zero with PX4. my ear is certainly bent to your, and othersā, commentary. apologies for anything that might be obviously ignorant and/or detrimental to the effort.
.
increasing density altitudecauses, in the case of FWAC, the need for a faster airspeed to maintain lift (obvious) over the wing. learning that lesson costs some pilots their planes when they visit from lower altitudes and fly (manually) according to their learned expectations. a lot of stalls on takeoff, (especially) landing and regular flight. Landing at a faster groundspeed means the reaction time needs to be faster, position prediction has to move forward, and ground handling skill has to improve.
ā¦THEN, add the wind and turbulence characteristic to my area and landing becomes a risky business for sUAS/RC.
ā¦ but gyros/stabilizers help immensely. im hoping the pixhawk/hack with px4 can take it the rest of the way for full autonomy (including landing) RELIABLY. glad to see you guys working on it.
.
ā¦ i keep wondering what PX4 can/canāt do. im hoping (big time) that it will be good enough to trust even an expensive plane to. ive been in the R&D electronics industry for over 30yrs now, so i understand software/hardware system relationships, expectations and capabilities. i believe the potential is there, at minimum. at present. im feeling pretty good about it.
uh oh, i just remembered this thread.
.
see this thread on Taildragger TO/landing for more comments.
Once release 1.9 is out the plan is to get to diving into this. Itās basically needs a rewrite. Maybe not in code but in process. We have 3 point landings down but the process is crap even though the end result is sufficient. While I usually care about the end result, not in this case as it is at the expense of added complexity and robustness. ie we having landing profiles depending on environmental factors. This has a lot of room to improve. Actually, not improve but really work. I canāt imagine that there are that many people out there flying 100ās of km testing landingsā¦ and since itās only specific to our planes, the settings are irrelevant for anything else.
Also, Iāve tried tail dragger takeoff but never steerable. They were so light they just got up and went but I havenāt messed with takeoff ground pitch.
sounds like fun.
the time ive had with it so far, i can see your POV. the takeoff seems to be rock solid (for a nosewheel plane) but the landings ive had are just so inconsistent - some are good, some are not, some are fails. but im not fully familiar with the effects of the parameter list as yet, so im still hunting for a dependable setup. wind certainly has a noticeable effect in changing the results given fixed params - even slight winds.
RWTOās and landings certainly seem like the minority in smaller drones, which is what px4 is aimed at? and, i realize, taildraggers are probably minimal (if existant) in commercial apps.
ā¦BUT, accommodation of taildragger TO/Landing only differs from trike gear functions as the airspeed slows on the ground. if the AP can handle it, eliminating the nosewheel might enable more camera/sensor use up front?
.
anyways, looks like 1.9 is, at last, close! im anxious to see what the lidar v3hp will do for landing consistency.
.
edit: aha! i see that ardupilot already has this taildragger TOL parameter set. i may switch over to that flight stack.
We recently started testing FW_LND_THRTC_SC on our airframe (foamy flying wing). It has a very noticeable improvement for glide slope control on landing, and therefore more accurate landings, especially in windy conditions. here is a flight log that shows improved glide slope control on landing using a FW_LND_THRTC_SC value of 0.5 (i.e. twice as fast throttle response):
https://review.px4.io/plot_app?log=ea0a0b1e-3a4a-4395-80ba-2d470013fb4c
@Antiheavy Would you mind sharing some details on your aircraft, i.e. Make/Model, wingspan, prop and motor combo, battery, takeoff weight, etc.? I have a couple of flying wings and would like to compare your settings for this against mine for testing as well.
Thanks
I would like to ask if anyone has done the simulation experiment of landing section of fixed wing UAV (preferably Maltab/Simulink)?
Good evening,
Having just played around with simulation in gazebo and test planning of missions, I have started to look around for information concerning the improvement of auto land as I found it quite difficult to get consistent results. I have found this discussion and agree with a lot of what was said here. Whilst this isnāt my first time using PX4 (despite this account being new) I have only worked with multirotor airframes before, thus fixed wing is quite daunting. Is there any development on this discussion or has this been moved elsewhere?
Many thanks in advance, WG_APS