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.

[rts18]

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.

@MrD-RC With respect I understand navigation isn't an area you often make changes; that would be @breadoven 's forte. However take my word for it. INAV does not compensate to the level of precision you may think it does.
Indeed it would be good to have a fix for this in the firmware, but we aren't there yet. This is a proof of concept that I am willing to test to improve waypoint ground and altitude tracking accuracy in higher wind conditions; with it only requiring the addition of a couple more operands.

@b14ckyy I see you understand the concept and eloquently described it. Thankyou! I was starting to pull my hair out over the interrogation.

[Jetrell]

@MrD-RC @b14ckyy
I see the point @rts18 is making.
Marc and I spoke on discord some months ago about ground speed and airspeed based throttle control. For the benefit of better WP tracking and turn accuracy for fixedwings when its windy.. Airspeed for Cruise and Ground speed (within limits) for WP targets.
I also eluded to it here when I was talking to @breadoven in one of his PR's.

I see there is benefit to reducing the throttle on the downwind leg of a mission, for a short distance leading up to a WP turn, to reduce the extra likelihood of the plane being pushed past the WP by the tailwind.
While increasing the throttle as the WP target is met. And continuing to apply more throttle for a distance after the WP turn, should help push or pull the plane more tightly through the turn.
Plus it could help provide the nav_fw_pos/vel_z controller with more airspeed, which in turn will give the elevator more authority (when a tailwind is present) to hold the target altitude.... Which is one of the reasons I believe the fw altitude controller is having issues with some airframes.. i.e. the airframe is effectively on the edge of an airspeed induced stall when the altitude controller commands it to climb to hold the target, after turning onto a downwind leg.

[sensei-hacker]

But surely that would be for a leg, not just a turn?

As discussed on Discord, the airspeed would recover after 3-10 seconds or so if throttle wasn't changed. One could say tailwind is pushing the plane forward, causing it to speed up. But that takes a few seconds. So the throttle increase is needed during and for a few seconds after the turn. To avoid stall right after turning downwind, BEFORE the wind "pushes" the plane to a higher speed.

Immediately after you turn downwind your airspeed may be close to zero - it will certainly be lower than it was crosswind. You can therefore look at it as being similar to when you first launch. You need launch throttle for a little while to build up speed, then you can reduce to cruise throttle.
Same after a turn downwind - you need additional throttle to get up to speed, then you can reduce to static cruise throttle.

This is mostly important when the wind speed is a significant percentage of the airspeed, as it is on most of my planes. If you're zipping around at 70+ knots the windspeed is probably a small percentage of that, and you probably have plenty of margin before stall. My builds tend to fly closer to 25-30 knots, so 12 knots of wind is the difference between cruise and stall.

[sensei-hacker]

Consider a Zohd Drift flying cross wind at 40 km/h. That's just 20% below the maximum safe speed of the plane. (The manufacturer warns against exceeding 50 km/h due to flutter).

Suppose the wind at altitude is 25 km/h.
Immediately after the turn, if you didn't increase throttle the ground speed is still 40 km/h, but the airspeed drops to 15 km/h! You will absolutely stall, if you don't increase throttle during and after the turn.

"When you set up cruise throttle, it should be set for the most efficient airspeed with a reasonable buffer over stall airspeed"

Setting cruise throttle 25 km/h higher would put you at 55 km/h, which is 5 over Vne and you would expect flutter may lead to loss of the airframe.

You may fly planes with 50 km/h difference between Vs1 and Vne. Not all of us do.

The Drift, for example, has Vs1 around 25, Vc about 38, and Vne of 50. So 15 -20 km/h of wind change due to a turn will result in either a stall or an overspeed if you don't manage the throttle and elevator.

Therefore flying at a constant throttle with the intent to fly crosswind at ( stall + wind speed + margin ) would almost certainly result in stall on downwind turns and overspeed on upwind turns, with flutter as the immediate result and loss of the airframe possible

[Jetrell]

But that takes a few seconds. So the throttle increase is needed during and for a few seconds after the turn. To avoid stall right after turning downwind, BEFORE the wind "pushes" the plane to a higher speed.

@sensei-hacker I agree...

The other area of navigation this is encountered is in Loiter circuits when its windy. This often leads to the plane holding altitude on the headwind side of the loiter and losing it on the tailwind side.
When looking over the logs of such flights, its noticeable to see the nav_fw_pos_z_p increasing. As does the pitch PID error and elevator servo output.. But the pitch2thr doesn't see enough angle change to increase the throttle, even by 1%.. Proving that pitch2thr doesn't cut-it in cases like this.

[MrD-RC]

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.

That scenario was never suggested. That may be useful. It may also burn more battery than required. Causing an aircraft to not make it home.

[MrD-RC]

@MrD-RC With respect I understand navigation isn't an area you often make changes; that would be @breadoven 's forte. However take my word for it. INAV does not compensate to the level of precision you may think it does. Indeed it would be good to have a fix for this in the firmware, but we aren't there yet. This is a proof of concept that I am willing to test to improve waypoint ground and altitude tracking accuracy in higher wind conditions; with it only requiring the addition of a couple more operands.

it doesn’t need to be an area I make changes in to know that something should be addressed by the firmware, rather than bodging things in the programming framework. The whole point is the programming framework should not be used to bandaid issues in the firmware. Those issues should be raised and fixed in the correct place.

@b14ckyy I see you understand the concept and eloquently described it. Thankyou! I was starting to pull my hair out over the interrogation.

The example Marc raised is not what you have been asking for at all.

[MrD-RC]

I agree with points raised by @Jetrell and @sensei-hacker. But, I don’t believe the solution to the issues they raised should be dealt with in the programming framework. They should be dealt with in the firmware.

[b14ckyy]

OK lets summarize before we beat our heads because of some semantics:

Wind Speed and Wind Direction has actually some use (Just while typing I think of a tail-wind warning when flying long range on the way out, with your new custom OSD Elements).
Changing config parameters is not an option (Cruise throttle) but can be done by manual throttle increase instead as it basically adjusts the cruise throttle to the stick position.
For Waypoint speeds no change is even needed as a throttle override + ground speed can be used here until such thing is in firmware.

end result: If Wind Speed and Heading would be input values for the Logic Conditions, everyone would be happy :D

[rts18]

The whole point is the programming framework should not be used to bandaid issues in the firmware. Those issues should be raised and fixed in the correct place.

@MrD-RC I understand your point. But I wonder if such an alteration to the navigation throttle control is a realistic option in the near future?

The example Marc raised is not what you have been asking for at all.

Also correct. However Marc grasped the idea behind my requests for these additions to the programming framework. And as stated; there are many use cases for these two operands. With all being related to some type of navigation control. Which may have been why you assumed I was referencing the same example twice.

I agree with points raised by @Jetrell and @sensei-hacker. But, I don’t believe the solution to the issues they raised should be dealt with in the programming framework. They should be dealt with in the firmware.

Once again, no argument from me. However I don't presume for you to take on the roll to fix and add new navigation throttle framework. That's not my personal style to request something that demanding.

To finish; @b14ckyy last post would cover all bases; both relating to all the aforementioned issues and more that could be dreamed up by other users. Not withstanding the additions of proper fixes in later releases; after tests with the programming framework have proven them to be viable options.
However you are one of the project developers and I respect your ultimate decision.

[sensei-hacker]

I agree with points raised by @Jetrell and @sensei-hacker. But, I don’t believe the solution to the issues they raised should be dealt with in the programming framework. They should be dealt with in the firmware.

I agree it would be good for the firmware to be aware of and address these issues. The development path for that could be similar to the path used for the auto land feature, or could be different.

I won't have time this week to develop it in the firmware. Is this something Darren has time to work on, or should we let people experiment with it via IPF first?

[MrD-RC]

I agree with points raised by @Jetrell and @sensei-hacker. But, I don’t believe the solution to the issues they raised should be dealt with in the programming framework. They should be dealt with in the firmware.

Once again, no argument from me. However I don't presume for you to take on the roll to fix and add new navigation throttle framework. That's not my personal style to request something that demanding.

But that's the point. Those things should be raised as issues. You're not demanding something of me. You're reporting that something isn't as it should be and requesting a fix. Which any developer can take on. Same as here you're requesting an addition to the programming framework. Which any developer can add.

I'd just much rather see problems be raised as issues than people trying to fix them themselves using the framework.

[trailx]

I agree that the ultimate implementation of widespread solutions should be addressed by the firmware. That said, there are niche problems that may only need to be solved by one person, thus would never get prioritized. Most INAV users are not devs or programmers, and while the programming framework is somewhat complex it does provide a route for non-devs to find and test our own solutions without risking anyone else's planes.

Testing updates to the firmware requires not only programming knowledge, but also building a hex file, which is beyond most of us. So there's a huge barrier and the programming framework is our workaround.

My point is simply that we can't anticipate all possible uses of the framework. Solving these niche problems is exactly why IPF exists. Therefore any additional parameters we can access through IPF could potentially be helpful to someone in the future. I'd personally love to see the current IPF I/O parameter list doubled.

If you want specifics, I've seen people on rcgroups mention that efficiency-related parameters (current mah/mile, and average mah/mile, etc) would have been helpful for a program. I've wished PIDs, filtered gyro signals, or filter settings were accessible for in-flight programmatic adjustments. Maybe someone could then develop their own auto-PID program, or a gains adjustment for the main PIDs like BF has. Filter settings available in IPF could be used to make an A/B test on a switch to safely try and fly different filter settings between a 'known good' and more paired down filter setting. This would effectively minimize risk to the plane.