Feature request : Add estimated Wind Speed and Direction as logic condition flight parameters

[rts18]

Desired Behavior

After talking with @b14ckyy about the matter of fixedwing auto landing and wind speed effecting the landing position. I was thinking it would be helpful to have the estimated wind direction and estimated wind speed added as flight parameters to the programming tab.

Who does this impact? Who is this for?

I believe this would help people to perhaps find a work-around to the aforementioned issue using the programming tab. Until a proper fix can be implemented at a later date.

Thanks for your consideration.

[b14ckyy]

In general I am always keen to see additional values usable for programming but I am curious, what you want to do with these values specifically.

[rts18]

I had an idea of using the estimated wind speed and direction, if applicable to the approach heading; to drive timer based throttle or elevator override conditions. To either push the nose down a little at select distances from the landing location. And add or subtract a small amount of throttle, based on the headwind and current altitude at a given position on the approach. Being permitted by setting nav_override_motor_stop = off or off_always

Don't shoot me for a theory. It would require some testing to see if the idea has merit; and it may not work. But considering wind speed and direction has such a strong influence on fixedwing flight. I thought the addition of these flight logic parameters would be useful.

[b14ckyy]

I see where you are coming from but there are some issues. During the approach the throttle is already reduced and should stay slightly above stall speed by that.* But we can't detect gusts in real time and only get an average wind speed while the plane is turning. Not during a straight linear flight (unless you have a Pitot tube).

We thought about changing settings like cruise throttle values with programming but after some debate it was considered too dangerous to change essential flight parameters by the programming framework.

Also you might have a false conception about airplane physics thats very common. Except for sudden wind speed changes from gusts, the airplane does not care about wind speed or direction. Imagine it like a swimmer in a river. For the swimmer the water stands still and no matter in what direction he swims, he will swim at the same speed relative to the water. The same is the case for planes. if you tune the navigation controller and Control loop in calm weather the plane will always fly no matter how much wind there is (unless its too excessive).

Another issue is, you never ever push the nose down to land. Flying a plane is constantly converting potential energy (altitude) with kinetic energy (Speed). If you push the nose down you will speed up and make the problem of a float worse. What you actually wanna do is, to pull the nose up to slow down and then sink to the ground faster.

This brings me to an idea... Have you ever tried to start the glide phase with a higher angle of attack, pushing the nose up 2-3° more to slow down further?

---

*We actually have some concepts about a different throttle control for INAV but we might not have the time to bring that in INAV 8.0. This would include a separate throttle value for the approach and makes the P2T modifier obsolete.

[rts18]

Thankyou for the information. I do understand the physics of aerodynamics, relative to air density.

The issue I see presently, is the glide approach angle is a product of the Approach altitude and the Approach length. With any reduction of the approach length or increase of the approach altitude, based on the necessity of terrain or obstacles; mostly always causing landing safehome overshoot.

Another issue is, you never ever push the nose down to land. Flying a plane is constantly converting potential energy (altitude) with kinetic energy (Speed).

You may have got the wrong idea of what I have in mind. I wasn't referring to pushing down elevator near the landing safehome. That would have the effect you mentioned. There are two ways you can land a model aircraft. The first is the way auto landing works, with a supposed linear glide slope between the aforementioned settings. The other is the way more experienced line of sight model pilots will some times land when required. By pushing the airplane into a dive a shorter distance out from the runway, then pulling back and letting the plane wash of speed at a lower altitude. Then e.g. flying the last 50m closer to the ground; then flaring and dropping it on the runway when ready.

Anyway. I won't rave on. I'll just wait and see if anything comes of this request and play around with the programing logic in the meantime. Thanks

[trailx]

I found this comment really interesting @b14ckyy :

We thought about changing settings like cruise throttle values with programming but after some debate it was considered too dangerous to change essential flight parameters by the programming framework.

If people are messing around with essential flight parameters in the programming framework, don't you think they understand the risks? I would love to see a TON of variables added to the programming framework including the PID controller values - which I assume would be considered essential flight parameters.

More essential flight parameters are what we need to work with in IPF, and its way more limited than it should be at present. IPF is the sandbox. Sure you may crash, but that's expected if you are messing with certain parameters, and its always a risk. Otherwise never take off.

[b14ckyy]

The main problem is, that we exhausted the capacity if the MSP protocol with all the settings and values loaded on that page. I have no idea about the details but @MrD-RC had to do some trickery already to raise the number of lines from 32 to 64. If we now add a bunch more parameters to select and change, every extra parameter raises the MSP payload more until we reach the limit again. Before we can go complete bonkers and add a ton of more stuff, it needs an overhaul of how MSP calls and writes the data.

Additionally we do not want to add any settings parameters. We have temporary overrides for some like loiter radius but they are not saved. For things like cruise throttle and other Settings parameters we would need to add temporary variables for each raising the ram and the code complexity significantly. Because you don't want to accidently save the changed value as the config value, right?

[trailx]

One potential workaround may be to utilize the adjustments tab in conjunction with IPF. This could get tricky, but if the flight parameters could at least be referenced in IPF, I wonder if we could trigger adjustment-tab changes with the IPF code without adding a bunch of additional MSP payload. I don't understand the limitations well enough to know if this is a solution to the issue.

[MrD-RC]

It wasn't trickery. The method for getting the LCs was just changed to allow for getting each LC individually, rather than as a single call. I've just done the same for the custom OSD elements.

There shouldn't be a problem adding more operands to the LCs. Only the ID is sent over MSP. So it wouldn't add any overhead.

The programming framework is an advanced feature. There are already parts of it that could easily down an aircraft if used incorrectly. For example RC channel overrides, axis reversal, throttle overrides, plus others.

I think adding to the programming framework. Each thing should be assessed on how useful it could be. Cruise throttle could be useful for closed loop speed control (PID + airspeed sensor). Wind speed and direction I'm not sure on though. As a temporary work-around until a feature gets a slight improvement doesn't seem like a good reason. It should be a permanent reason. I definitely don't think access to the stabilisation PIDs should be in there either. They should be managed by internal means. Which could include things like switching from TPA to APA (Airspeed PID Attenuation, potentially using virtual airspeed even).

[MrD-RC]

I think Inflight Adjustments and the Programming Framework should remain separate. Inflight Adjustments are mostly for tuning these days. So what they do shouldn't need to be accessed all the time.

[trailx]

Hey as long as APA is a planned feature, I'm satisfied. My current APA implementation of switching the PID profiles in IPF based on airspeed is far from perfect.

But that exhibits the problem. We can't anticipate all everything that people want to solve in the programming tab, so shouldn't we make as much available as possible? That's kinda the nature and point of IPF.

Likewise, the more that can be made available in the adjustments tab, the better. (The issue there is just with OSD visibility of all the parameters.)

[MrD-RC]

Not really. The purpose of the programming framework is to allow people to add fairly basic functionality. Anything complex or potentially dangerous should be a part of the main firmware, and well developed.

The programming framework could be used as a test bed for some features. As @b14ckyy demonstrated with autoland. But it's not intended to solve complex problems.

[rts18]

As a temporary work-around until a feature gets a slight improvement doesn't seem like a good reason. It should be a permanent reason.

@MrD-RC Thankyou for chiming in. That was only one reason I provided based on this topic. However I can also think of other uses for these conditions. I just didn't want to write a page full of explanations, to side track the original request. But if this request isn't going to go anywhere. Should I just close it?

@trailx You raised a good point in your first post. We aren't all newbies. Many of us have considerable RC, FPV and INAV experience. We are aware of the risks; and mitigating them by thoroughly testing changes on the ground first and then under controlled conditions in the air; for our own safety, as well as the public and for the longevity of the aircraft.

I occasionally drop by this repository to see what changes are in the works. I have read a few posted over the years from contributors, stating how they find the programming tab to be extremely useful; as they went on to say its more preferred for them to use than writing a pull request and stuffing around with Github. @b14ckyy is a good example of this. He is extremely knowledgeable of INAV operation. But by his own admission, lacks coding experience. This doesn't mean he isn't capable of adding to INAV. It just means he would be more confident in using the programming tab, than making advanced changes to the navigation code library. I am of this same line of thought; as are many INAV users. The programming tab IMO is the greatest assets INAV has over other flight software.

[sensei-hacker]

But if this request isn't going to go anywhere. Should I just close it?

I don't see anyone saying it can't or shouldn't be added. B14ckyy brought up the MSP thing, but MrD addressed that - it's not a problem.

Things just get discussed, because being mindful and discussing changes is how we improve the quality of INAV.

If I get time (not super likely), I may add estimated wind to IPF soon, make a pull request. Or rts18, you can look at one of the other PRs that added something to IPF and try your hand at adding this value.

[MrD-RC]

What examples can you think of for adding wind direction and speed to the programming framework?

[rts18]

cruise throttle could be useful for closed loop speed control (PID + airspeed sensor).

You raised this one a few posts back.

Having a operand for wind speed and not just airspeed; removes the need to calculate wind speed based on addition or subtraction of the ground speed. Which could potentially take up an extra half dozen lines in the programming tab.

An example a few of us had pondered, was a limited throttle range management. Which could be applied to waypoint mode. The idea of such a function would allow the throttle to be increased for a time, after a turn has been made onto the down wind leg of a mission to prevent altitude loss. It could also be used to dictate the approach speed to a waypoint; by reducing the throttle up until a set distance before the waypoint, then applying more throttle as the waypoint position is met. Using distance from waypoint operand and nav_override_motor_stop = off , nav_fw_manual_throttle_increase = ON settings. This idea would benefit from both wind speed and direction.

Please note; I am fully aware of the extra logic, timers etc required to make this work as described. Thankyou for the inquiry.

[MrD-RC]

But you don't need to calculate wind speed if using airspeed. The aircraft doesn't care.

Your answer is still based on a hack for the autoland. Forgetting that totally. Why would you want wind direction or speed in the programming framework?

[rts18]

Your answer is still based on a hack for the autoland.

No. You ask for another example. Isn't that what I provided you? I have so far provided two possibilities. I can provide another if needed. I have had many ideas that would be interesting to implement. Idea's that the SITL's flight dynamics are not able to correctly simulate. The next step is to move to the possibility of real world testing. Something that the programming tab has potential to provide.

But you don't need to calculate wind speed if using airspeed. The aircraft doesn't care.

That is correct. However it does provide a reference point for the magnitude of the airspeed. This allows for the application of the flight logic under these specific conditions of the examples given.

[MrD-RC]

An example a few of us had pondered, was a limited throttle range management. Which could be applied to waypoint mode. The idea of such a function would allow the throttle to be increased for a time, after a turn has been made onto the down wind leg of a mission to prevent altitude loss.

This shouldn't be necessary if the navigation is tuned correctly. INAV should compensate for this, regardless of wind. Again, you shouldn't need programming framework routines to try to fix fundamental navigation issues if they exists. If this is a problem, it should be fixed in the firmware.

It could also be used to dictate the approach speed to a waypoint; by reducing the throttle up until a set distance before the waypoint, then applying more throttle as the waypoint position is met. Using distance from waypoint operand and nav_override_motor_stop = off , nav_fw_manual_throttle_increase = ON settings. This idea would benefit from both wind speed and direction.

I don't understand why anyone would want to do this? When you set up cruise throttle, it should be set for the most efficient airspeed with a reasonable buffer over stall airspeed. So why would you want to slow down on approach to a waypoint? WP mode uses auto throttle; which has a minimum of cruise throttle (unless you are descending where P2T could reduce it) or minimum ground speed, whichever is higher. So you couldn't reduce below that anyway. You could use throttle override to increase the throttle above cruise throttle. But surely that would be for a leg, not just a turn? Wind shouldn't matter, as cruise throttle should be set at a reasonable amount above stall airspeed anyway.

I know a waypoint can have a speed. I believe this only works with multirotors currently. So perhaps implementing waypoint speed for fixed wing would be useful. I believe there are even flags still available. So there could be a choice between throttle percentage or airspeed (if available). But even then, cruise throttle should be the minimum throttle setting.

[b14ckyy]

I think his point is, to compensate for wind speed and direction to maintain a more or less constant groundspeed when flying in headwind during a WP mission. This is indeed a useful scenario imho.

if INAV ever gets a airspeed based throttle control be actually possible to have certain speeds for waypoints predefined (with a minimum airspeed set) to have consistent over ground flight speeds during waypoint missions. This would be helpful for search or mapping operations.

having some kind of control over cruise throttle with programmed triggers, would still be an interesting feature for such scenario. although I would rather control the cruise throttle value based on ground speed and that would not need wind speed and direction.