Fixed wing Auto Speed Mode

[breadoven]

Adds Auto Speed mode for fixed wing similar to #10928.

Operation is pretty simple. It is enabled as an aux mode so can be activated in the usual way. Minimum and maximum allowed speeds are set using 2 settings with a range of 5 to 50 m/s, defaults of 11m/s and 22m/s respectively. The desired speed is set between these limits using a control such as the throttle stick (default) which acts as a speed controller. The control used can be selected with a setting that defines the channel used by the control. Speeds are either Pitot airspeed or 3D GPS based (so a valid velocity estimated is required) defaulting to Pitot airspeed if installed. If airspeed isn't required it can be disabled via a new logic condition that has been added.

An OSD element has been added which displays the current set speed, this is only visible when Auto speed mode is active. The OSD element also indicates which speed source is being used, Ground or Airspeed, and whether or not Auto speed is active, displaying "OFF" if the mode is selected but not active.

Throttle is automatically controlled using PID control with P, I and D inputs with filtering to damp out rapid throttle changes. In Nav modes the normal fixed wing pitch2throttle control is bypassed when using a Pitot. Minimum ground speed throttle override is still active for Pitot and ground speed based control.

There is no maximum throttle limit set at the moment. Minimum throttle is dynamically limited in ground speed mode based on cruise throttle + pitch2throttle settings, but Pitot speed mode is always limited to Idle only. Motor stop is disabled when using Auto speed regardless of other Nav settings. In light of this, for safety reasons, Auto speed mode is included in the Nav arming blocker so must be disabled before arming and it also won't activate until the plane is detected in flight.

The mode can be activated in all cases except during during Failsafe and Emergency Landing and certain phases of Nav modes where it's not sensible to use it. So it can be used in Manual and Acro as well as navigation modes.

Currently there is no way to rapidly shut off the mode other than via the aux activation. This may need to be looked further if it's considered a problem together with other changes to improve functionality such as dealing with strong head winds etc.

HITL tested only at the moment where it works well with the default PID tune. Throttle control is smooth and responsive. Behaviour in strong wind works as expected with minimum throttle protection preventing stall when flying down wind using ground speed as the reference.

Configurator support iNavFlight/inav-configurator#2641.

Airspeed override logic condition example:

[qodo-code-review]

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

[github-actions]

Test firmware build ready — commit 8f4070b

Download firmware for PR #11595

243 targets built. Find your board's .hex file by name on that page (e.g. MATEKF405SE.hex). Files are individually downloadable — no GitHub login required.

Development build for testing only. Use Full Chip Erase when flashing.

[Jetrell]

@breadoven Firstly I want to start by saying how much we all appreciate your work here on INAV. ❤️
And what follows is not ingratitude. But rather, just putting the facts out there.

When I setup the fixedwing auto speed mode with the IPF. I also tried a simplified version as you have here. But found it was just too lacking in many area's of safety of operation, and efficiency.
I noticed you mentioned many of these other issues. But I thought a rundown of why I added these extras, might help.

Example:

• The Min and Max throttle value the throttle controller can use. Plays a big part in how efficient the system can work. So their addition is practically a must.
  Plus if you do add those setpoints. It isn't a good idea to share them with nav_fw_min_thr and nav_fw_max_thr. Because altering them will significantly effect the way Pitch2Thr works when not using auto speed mode.

• I also tried using the throttle stick to set the speed target.
  It only worked very average. Because whether you fly with stick mode 1 or 2. Most of us move the throttle stick little by little as we make an aileron or rudder input. Causing the target speed to shift, and constantly require resetting.
  Even with a throttle deadband. It still occurred when flying in Acro.
  And using the throttle stick to set the speed target also rules out a safety shut off of auto speed mode. As you would have noticed. I used a delta (mildly faster) movement of the throttle stick, to exit auto speed mode if an emergency happens. Which it did once. And by pulling the throttle lower or even higher, it switches back to manual throttle control.
  I know the addition of a pot for speed target control, requires the use of an extra channel, But it does make it worth while. However I also tried just having the target setpoint being hard set as well, to a cruise speed that suits the pilots requirements. That too work well if channels are lacking.

• I also found that 3Dspeed required the "tailwind" safety airspeed throttle-up addition, to stay ahead of a low airspeed stall, if the plane was commanded to climb manually or by nav control when in RTH or a mission.
  Which would also require a setting, but I found it was absolutely worthwhile from a safety stall perspective.

• And Airspeed target was something that I noticed many people asked about. And i did find it advantageous for flight efficiency. The main time 3Dspeed was better, is if you wanted to make good headway into a strong headwind. And make it to your destination faster.

• I also found having the auto speed Throttle element on the OSD helped to determine how well the system was working. It provided a good visual reference when tuning and when commanding a steep dive or climb, so you could see how efficiently throttle was being feed-in, to hold the target speed.

I no this was long winded. And I'm not trying to make more work for you. But I thought it might be helpful for you to know what I also tried. So the feature can be made safer and more user friendly.
Plus if this feature is implemented to a higher standard, it leaves the door open for so many better fixedwing improvements.
e.g.
Fixed airspeed when running autotune. Which provides a more accurate FF and Rate tune.
I also tried using in with AutoLaunch. It also improved climb out efficiency, without risking a stall.
And it also help slow the plane, without risking a stall, when I tried it with fixedwing auto landing mode.

[breadoven]

@Jetrell I probably should have said this is a work in progress. The initial build was just for basic testing in light wind but obviously is limited otherwise.

I've made some changes in the latest commits:

Added pitot
Pitot will be used by default if available. There is no means of actively selecting between pitot and ground speed ... at the moment. One issue with the virtual pitot I noticed is that its usage isn't dependent on isEstimatedWindSpeedValid so that's been added. However, the check for isEstimatedWindSpeedValid doesn't look too useful with it typically taking 15 mins to timeout and become invalid if you're not manoeuvring. This seems to have come from the research paper used for the theory but doesn't seem realistic for real world use. I think a shorter time period should be used here, probably < 5 mins.

Added stall protection when using ground speed
This is based on existing cruise throttle and pitch2throttle and sets the minimum allowed throttle.

Added low ground speed protection
This uses the existing logic which works albeit crudely but I guess it's really just a last resort thing. One issue here is the Nav Pos and Alt controllers shut off if ground speed drops below 3m/s. This doesn't make sense if you have a pitot so the logic needs reconsidering where airspeed is available.

Added a NAV_CTL_SPEED flag
Allows activation in all Nav phases where it makes sense including during most Auto landing phases.

Things that need further work:

1. Adding Max/Min throttle settings - this is trivial to do so not an issue. Although is this not more related to Max throttle than Min ? As mentioned above min speed using ground speed is dynamically set by cruise throttle and pitch2throttle settings. And with pitot I don't see the issue with allowing idle throttle, e.g. in dives.
2. Using speed demand methods other than throttle - probably a personal preference thing but I can see the issue with the other control axis upsetting the set throttle position.

I also found having the auto speed Throttle element on the OSD helped to determine how well the system was working. It provided a good visual reference when tuning and when commanding a steep dive or climb, so you could see how efficiently throttle was being feed-in, to hold the target speed.

I'm not sure what you mean here. The normal OSD throttle display shows the Auto Speed throttle setting the same as any other auto throttle mode. The only OSD element that's been added for this PR displays the selected speed, (300U) or (ASPD) if Autospeed mode is ON but not active. This could be changed to show if airspeed or ground speed is being used I guess, e.g. G: 300U vs A: 300U.

[Jetrell]

isEstimatedWindSpeedValid doesn't look too useful with it typically taking 15 mins to timeout and become invalid if you're not manoeuvring.
I think a shorter time period should be used here, probably < 5 mins.

I totally agree. The wind can swing in as little as a couple of hundred meters. So 15mins seems extreme. I figured it was just set this high, so virtual wind/airspeed wouldn't become invalid and cause issues with something that was relying on it.

Although is this not more related to Max throttle than Min ?

Max throttle is more beneficial for power efficiency. But limiting Min throttle to a value higher than zero. Has two benefits that I found.

1. The first could stop a possible ESC desync, in the case of the plane pulling a loop in Acro mode. It will shut the throttle down in the diving half of the loop. And then the p term will apply Max throttle in the climbing half of the loop. I've seen it throttle-up very hard and fast.
2. The other is that a propeller (disc) that is spinning at lower speeds creates more drag, than a propeller that has stopped spinning. This is useful to help the auto speed mode hold the target speed in a dive.

The normal OSD throttle display shows the Auto Speed throttle setting the same as any other auto throttle mode. The only OSD element that's been added for this PR displays the selected speed

Sorry, I could have worded that better.
What I meant was not Nav Auto throttle.. It's OSD element will be displaying what auto speed mode is outputting when the plane is in a navigation mode.
But when the plane is in Auto speed mode and flying in Acro, Angle , AngleHold, Horizon or Manual. That OSD element will only display the manual throttle value. Not the output of the Auto Speed mode controller.
That was why I mentioned having it as its own throttle element is very useful.

[breadoven]

1. The first could stop a possible ESC desync, in the case of the plane pulling a loop in Acro mode. It will shut the throttle down in the diving half of the loop. And then the p term will apply Max throttle in the climbing half of the loop. I've seen it throttle-up very hard and fast.

There is filtering on the throttle output that damps the rate of change so maybe it's not an issue in this case.

2. The other is that a propeller (disc) that is spinning at lower speeds creates more drag, than a propeller that has stopped spinning. This is useful to help the auto speed mode hold the target speed in a dive.

This PR honours motor stop where applicable, Acro, Manual etc, but it could be changed to prevent that and have Idle as the minimum allowed always. I left motor stop behaviour as is to avoid surprises, e.g. in Manual, although that could be fixed by only allowing activation when in flight.

The normal OSD throttle display shows the Auto Speed throttle setting the same as any other auto throttle mode. The only OSD element that's been added for this PR displays the selected speed

Sorry, I could have worded that better. What I meant was not Nav Auto throttle.. It's OSD element will be displaying what auto speed mode is outputting when the plane is in a navigation mode. But when the plane is in Auto speed mode and flying in Acro, Angle , AngleHold, Horizon or Manual. That OSD element will only display the manual throttle value. Not the output of the Auto Speed mode controller. That was why I mentioned having it as its own throttle element is very useful.

This shows the Auto throttle OSD display whenever Auto Speed is active, so it also works for non Nav modes.

[Jetrell]

The maintenance-9.x branch was damage a week back, and was retired. It would seem like this may have been built upon it. The tuning tab won't load.
I think @sensei-hacker has now repaired and replaced it for 9.1.

And when I was going to set it up on a plane. I could only find Auto Speed in the modes. But I couldn't find an activation setting or channel selection to choose between 3DSpeed, and Airspeed, while in flight.
I guess that would require two modes. One for each speed type. So the different slider positions could be placed on the same RC channel,

[breadoven]

The maintenance-9.x branch was damage a week back, and was retired. It would seem like this may have been built upon it. The tuning tab won't load. I think @sensei-hacker has now repaired and replaced it for 9.1.

It was built on the maintenance 10.x branch so I don't know if that also has a problem related to 9.x. @sensei-hacker ?

Edit: I just checked and I also can't get the Tuning tab to work in Configurator with the changes for this PR or the 9.0.2 version so there must be something in the firmware that's broken.

And when I was going to set it up on a plane. I could only find Auto Speed in the modes. But I couldn't find an activation setting or channel selection to choose between 3DSpeed, and Airspeed, while in flight. I guess that would require two modes. One for each speed type. So the different slider positions could be placed on the same RC channel,

At the moment there is only the Auto Speed mode. As it is this PR will use airspeed if a pitot is active, otherwise it uses ground speed. There is no means of swapping between airspeed and ground speed and I don't think it makes sense to do this by using up a mode. Would be better to use programming probably which should be easy enough to add if not already possible, I haven't checked.

[sensei-hacker]

It was built on the maintenance 10.x branch so I don't know if that also has a problem related to 9.x.

maintenance-10.x is not affected by the same issue.

The problem was that maintenance-10.x commits got leaked into maintenance-9.x.(which I then reverted, meaning there are commits add and removing the changes).

[breadoven]

It's probably an MSP issue related to the new PID this PR adds. Need to check it further.

[Jetrell]

Would be better to use programming probably which should be easy enough to add if not already possible, I haven't checked.

Using the IPF would be okay.
Otherwise it means the user would have to disable their pitot, removing the other benefits it adds, just so they could use 3Dspeed auto speed. Which isn't ideal.

[sensei-hacker]

This PR honours motor stop where applicable, Acro, Manual etc, but it could be changed to prevent that

IMHO people who want motor stop off can (and probably do) turn it off. Those who want it on can turn it on. I don't see any reason for this mode to override the pilot's specific instructions.

[sensei-hacker]

It's interesting to me that some RC folks still say this "a propeller that is spinning at lower speeds creates more drag, than a propeller that has stopped spinning". NACA, the predecessor of NASA, tested this properly in the 1930s -1940s and got solid data. (The 1930s and 1940s saw a great need for advancing research on airplane performance, for -- reasons).

See:
NACA Report No. 641 Hartman, Edwin P., and Biermann, David. (1938). "The Aerodynamic Characteristics of Full-Scale Propellers Having 2, 3, and 4 Blades." National Advisory Committee for Aeronautics (NACA).

NACA ARR No. L5A13a / Walter A. Bartlett Jr. (1945): "Wind-Tunnel Tests of a Dual-Rotating Propeller Having One Component Locked or Windmilling".

Quoting the NACA technical memorandum "Improving the Performance of Multi-engined Airplanes by Means of Idling Propellers:
"the 'free-wheel' Propeller significantly minimizes the braking effect of a stopped engine."

The reasoning for thinking otherwise may be either using the reference frame of a person standing on the ground rather than the airplane's frame of reference, or forgetting that fighting the torque takes energy? Forgetting that you're using up energy fighting the spin (that energy coming from aileron drag fighting the torque). I've seen that in "testing" where they have the apparatus anchored to a table and forget to measure the torque applied to the table. From that testing, we can conclude that stopping the motor is better -- but only if the plane is anchored to a table while flying.

Looking at it from the relevant frame of reference, that of the aircraft, perhaps we can see that a prop that is freewheeling is free-wheeling WITH the airflow? It's moving right along with the air, minus motor friction. Therefore isn't a prop "stopped" from the frame of reference of someone on the ground one that is moving AGAINST the airflow. Probably nobody thinks that having the prop go BACKWARDS against the airflow would make it more efficient, but from the point of view of the airflow, a braked prop is moving backwards relative to the flow - it's not moving with the airflow. That seems to be what the professional researchers have found?

Or perhaps one could look at this way:

Is applying a little bit of backwards force to make the propeller not go with the airflow but instead match the person on the ground exactly the same thing as applying a lot of backwards force to make it spin backwards relative to the guy on the ground? Does the research over the last 90 years by NACA, NASA, DLR and others indicate it's doing precisely the same thing, just in different amounts?

[Jetrell]

"the 'free-wheel' Propeller significantly minimizes the braking effect of a stopped engine."

It all depends on the ESC setting state.
If the ESC is running Passive Freewheeling (asynchronous). Then it will rotate like a windmill. With little drag.

But if Active Freewheeling (synchronous rectification) is applied. The motor acts as a regenerative drag brake.. Not stopping the motor, but impeding the airflow through the propeller disc .

[breadoven]

The main reason for keeping the motor at idle is simply because a mode like this may demand max throttle regardless of throttle position (or some other control being used for speed demand for that matter). If you allow motor stop the motor will go from stop to max instantaneously as soon as the throttle is raised slightly which isn't desirable and I don't think normally happens in any other mode.

I never liked the motor behaviour before nav_overrides_motor_stop was added when the motor went from stop to cruise throttle in Nav modes, banging on and off with the throttle stick around the low point. It's not healthy especially with things like folding props.

Having said that you could add something to limit throttle acceleration if the motor is stopped so not an issue to fix if need be and I guess it also depends on whether or not the ESC has soft start.

And the Tuning tab in Configurator should be working correctly now with the PID settings for this added.

[Jetrell]

And the Tuning tab in Configurator should be working correctly now with the PID settings for this added.

Did it work for you ? I tested the last commit with the Configurator build for this PR, and also with the RC1 release. And the Tuning tab still would not open for me.

motor went from stop to cruise throttle in Nav modes, banging on and off with the throttle stick around the low point. It's not healthy especially with things like folding props.

Yeah true. And some ESC software's (Oxbot) have trouble with this instantaneous smash of the throttle.

[breadoven]

And the Tuning tab in Configurator should be working correctly now with the PID settings for this added.

Did it work for you ? I tested the last commit with the Configurator build for this PR, and also with the RC1 release. And the Tuning tab still would not open for me.

I think you'll need to use the version from actions for the last commit:

https://github.com/iNavFlight/inav-configurator/actions/runs/27044501551

[breadoven]

I also see your point here too, But even fw_auto_speed_level_min_thr could be overcome as well if the tail wind was strong enough and its value was set too low.

Nope, it makes no difference what the tailwind is, the throttle dictates the airspeed regardless. Once a plane is off the ground the only thing that matters is its speed relative to the airmass around it and that speed is essentially dictated by throttle. Ground references only matter if you're doing something that's related to the ground such as using ground speed or a ground position otherwise things such as head/tail winds are irrelevant to how a plane behaves.

And also noting the aerodynamics at play.. Even if the planes speed setpoint was 60km/h and the tailwind is 60km/h (0 airspeed). This doesn't mean the aerofoil is moving through a vaccuum.. The air in front of it still has density. Hence why a sailplane doesn't stall flying level downwind.

A sailplane doesn't stall because, in the absence of lifting air, it's always descending to maintain airspeed. In fact if it tried to fly level and maintain altitude it would stall. And it doesn't matter if it's flying downwind, upwind or crosswind, all those terms are irrelevant to a plane flying in an airmass moving relative to the ground, the only thing that matters is the plane's speed relative to the airmass.

Anyway I'll have a look at doing something using airspeed to aid the ground speed mode stalling problem that would avoid use of pitch2thr. If you have airspeed then I guess why not use it. But then again if you have airspeed and it's more reliable than ground speed, why use ground speed in the first place other than in certain situations where it might be beneficial such as flying into wind possibly.

[breadoven]

Latest commit changes ground speed behaviour to integrate it with airspeed if available. Changes:

1. Ground speed target speed is boosted by tailwind + min speed adjustment to allow auto speed to actively control during downwind flight without relying on a fixed throttle setting and pitch2thr. This remains active until speed demand has increased to the point where airspeed exceeds min speed.
2. An airspeed boost function has also been added to boost speed if airspeed falls 5% below the min speed setting. This resets when speed returns to the min speed setting.

If either of the above airspeed boost functions are active when using the ground speed source the OSD speed demand setting will display an alternating A and G on a 1 s cycle to indicate that ground speed is being overridden by airspeed.

If no airspeed is available ground speed reverts to using fw_auto_speed_level_min_thr and pitch2thr for stall protection.

The throttle filter f_cut has also been reduced to 0.25 to help smooth out throttle changes some more. Probably needs to be a setting ... to do.

[Jetrell]

Thanks for persevering.
I tested it again today with the last commit.
3Dspeed now works as expected in all wind directions. With Airspeed overriding 3D speed when the tailwind causes the Airspeed to drop below fw_auto_speed_min_speed.
I noticed the Ground speed letter switch back to the Airspeed letter for a moment. You would not likely notice it if you weren't watching for it; in the same way a system message would standout.

Loops in 3Dspeed are also much smoother now. With the setpoint being tracked noticeably better than it was previously with pitch2thr getting in the way. The change you made to throttle filter f_cut could have also helped with this.
As for that filter. I didn't really notice any delay in the throttle application in nav modes, when a climb was commanded. But did notice a slight delay, if I pulled back on the elevator stick quickly to start a loop. But nothing really to be concerned about.

I also tested it with the Pitot disabled, flying downwind... I left fw_auto_speed_level_min_thr at 1300us. But I only seen it drop to 35%, on several attempts. Even with a 26km/h tailwind.
However, as expected, the downwind 3Dspeed did get pushed past the setpoint with this method. But obviously not as bad as it did when it was using Cruise throttle.

I tested it in RTH, Loiter, Acro, Manual, Cruise, Coursehold, AngleHold and WP. It work fine in them all.

Now that pitch2thr is out of the way. The P and I could be tuned tighter, to reach and hold the speed setpoint even better.
I noticed a significant difference when I increased nav_fw_auto_speed_p = 35 and nav_fw_auto_speed_i = 20. This wasn't causing any throttle oscillations. And could even be pushed higher. But the efficiency started to reduce when taking the p-term higher than 40.
But it sure does hit the altitude climb rate in a hurry if set to 50.
However I would certainly recommend an increase in throttle i-term. 5 is far to low now. Leading to noticeable target drift.

I would also recommend increasing fw_auto_speed_min_speed default to 13m/s for a larger safety margin. Now that it's used to trigger the low Airspeed override of 3Dspeed.

If there was one last thing that I would still recommend to make this feature complete and a bit safer. It would be a bailout, by pulling the throttle stick low.
It makes no difference to me... But I'm sure someone will forget they are in auto speed mode. Then get in a panic situation and pull the throttle stick low. Then wonder why it doesn't shut off. Especially in a non nav flight mode.

[breadoven]

Throttle smoothing setting added and also throttle stick emergency stop.

Throttle smoothing allows f_cut to be adjusted from 1 to 0.1 which should be adequate. 1 will offer little smoothing and 0.1 will probably be too much with poor throttle response.

Throttle stop only works if not using the throttle stick for speed demand and it doesn't latch just switches the mode off at throttle low.

Also removed the ability to use this with Manual mode on after thought. Manual should be purely manual ... no auto functions allowed.

[Jetrell]

Throttle stop only works if not using the throttle stick for speed demand and it doesn't latch just switches the mode off at throttle low.

I was thinking about this.. Not having it latch OFF could be a problem if auto speed mode is accidentally left active at a lower target speed, when making a landing approach. And the user pulls the throttle low to glide, which shuts it OFF, then they raise the throttle again because the plane fell a bit short of the landing zone.. Wouldn't this cause auto speed mode to become active again under less than ideal conditions ?

And it also takes away this emergency exit safety feature for what ever percentage of users who have a spare RC channel, and prefer to place the speed target setting on that channel.

EDIT:
II wasn't sure if you had also accounted for the user having auto speed mode active in FW VTOL mixer profile. And the mixer profile is changed to the MC VTOL state ?

[breadoven]

I was thinking about this.. Not having it latch OFF could be a problem if auto speed mode is accidentally left active at a lower target speed, when making a landing approach. And the user pulls the throttle low to glide, which shuts it OFF, then they raise the throttle again because the plane fell a bit short of the landing zone.. Wouldn't this cause auto speed mode to become active again under less than ideal conditions ?

It's ultimately up to the user to decide how to use the modes available. I wouldn't use Auto speed when landing manually other than when some distance from hitting the ground.

EDIT: II wasn't sure if you had also accounted for the user having auto speed mode active in FW VTOL mixer profile. And the mixer profile is changed to the MC VTOL state ?

I guess the mode would simply shut off when it switched out of FW profile although I haven't checked exactly how this would affect things. Although again ... would it make sense to use this mode when switching VTOL modes ?

[Jetrell]

It's ultimately up to the user to decide how to use the modes available. I wouldn't use Auto speed when landing manually other than when some distance from hitting the ground.

It wasn't so much about landing with it deliberately on, but by accident. Which it isn't too hard to do. I've almost done it a couple of times with this PR, because the OSD activation element doesn't stand out anymore than any other OSD element.
And to be honest. Fixedwing auto speed control just makes flying incredibly easy when you don't have to manage the throttle.
I'm not trying to be difficult. Its just that the little touches can make all the difference for new users who rely heavily on software checks that prevent them doing things that could cause a problem... Which in this case is providing a low throttle exit that latches Auto Speed off until the activation switch is cycled, regardless of what RC channel they place the target speed adjuster.
As I said earlier. It makes no difference to me. But after talking with many thousands of users over the years. I know this will absolutely help someone.

Although again ... would it make sense to use this mode when switching VTOL modes ?

With greater VTOL automated mission support being added to 10.0 in this PR #11553.
I would say your feature here will often be combine with VTOLs on missions.

[rts18]

A friend and I gave this some use the other day. It worked well for us in the most part.
I don't think nav_fw_auto_speed_d is needed. Airplanes can't respond fast enough to make use of it. P & I required increasing from defaults.
I had to dig through the comments to find how to get 3D speed working. Finally found it. I must say not the prettiest.

[breadoven]

I don't think nav_fw_auto_speed_d is needed. Airplanes can't respond fast enough to make use of it. P & I required increasing from defaults.

Yes I noticed the D term doesn't do much but this is the same for other FW Nav PID loops also. It would be useful if you could provide your P and I terms to tune these in better taking into account the numbers @Jetrell provided above and those from some actual testing I managed to do myself (not HITL stuff).

I had to dig through the comments to find how to get 3D speed working. Finally found it. I must say not the prettiest.

Well this can always be changed if using logic conditions is considered too onerous. Adding another mode to cover this is a simple thing to do if need be. There will be something added to the Wiki mode description describing how to use the logic condition which once set up just behaves as a dedicated mode does although I agree it's not as convenient.

[rts18]

@breadoven

Well this can always be changed if using logic conditions is considered too onerous. Adding another mode to cover this is a simple thing to do if need be.

I understand your reason for using the IPF. But I reckon another mode would make selection easier for most people.

We settled at nav_fw_auto_speed_p = 33 and nav_fw_auto_speed_i = 22. But tuning can vary based on the airframe drag and the motor power output. And maybe personal taste.
I read Jetrell's findings #11595 (comment). We also found the base tune was a little weak.

When flying, talking back and forth. We noticed how different our auto speed throttle values were, when holding the same speed target. Her airplane has a lower drag coefficient than mine.

Something else we uncounted, as was raised in other comments. Is fw_auto_speed_channel. She used an aux channel. And I used the throttle stick to begin with. But I later added a workaround in Edgetx logic to prevent the speed target from being accidentally shifted by the rudder stick while in Acro flight.

[error414]

is it enought stable to test it on aircraft?

[breadoven]

is it enought stable to test it on aircraft?

Should be fine although you may want to change the PIDs in accordance with the comments above, i.e. increase P a little and I a lot (20 of so).

Edit: I changed the PIDs so the defaults should now be inline with the comments above. The I term default of 10 is the equivalent of 20 as mentioned above because the scaling factor for I has been halved. So default of 10 is the right value to use as it is.

[sensei-hacker]

it makes no difference what the tailwind is, the throttle dictates the airspeed regardless. Once a plane is off the ground the only thing that matters is its speed relative to the airmass around it and that speed is essentially dictated by throttle.

That's important to keep in mind.
Of course, it's only strictly true until you turn. Or there is a wind gust.

TURN from a headwind into what is now a tailwind and we'll quickly discover inertia. When there is a sudden GUST of wind, Newton's first law is in full effect and our relative airspeed immediately drops or increases for a few seconds, until our motor overcomes inertia.

So that's something to keep in mind when setting minimum throttle. It should be high enough to have margin for changes in relative wind over a few seconds.

[Jetrell]

So that's something to keep in mind when setting minimum throttle. It should be high enough to have margin for changes in relative wind over a few seconds.

This is why I recommended fw_auto_speed_min_speed default be set to 13, instead of 11. Because most users don't often change defaults. This being more beneficial for the use of the 3Dspeed based target, than the Airspeed target.
But most RC model planes have a much lower wing loading than full size aircraft. Which helps considerably, and reduces the chances of a downwind tip stall in a turn.

Most users will likely use the Airspeed target for increased flight efficiency. However I more often use the 3Dspeed target, for WP missions and general flight. Because a ground based speed reference is far more useful when tracking ground based references. Or even for the speed reference between two aircraft, when flying together.

I have flown with this and the IPF version many hundreds of times, over the last year. In winds up to 40km/h.
And with them pushing the 3Dspeed target ahead of the minimum, if a tailwind picks up. I have never encountered a stall or tip stall in a downwind turn, on half a dozen different airplanes.

[breadoven]

TURN from a headwind into what is now a tailwind and we'll quickly discover inertia. When there is a sudden GUST of wind, Newton's first law is in full effect and our relative airspeed immediately drops or increases for a few seconds, until our motor overcomes inertia.

A plane has no concept of head and tail wind though, they are ground reference terms only, so it makes no difference which way you're turning once in flight. Turning itself affects airspeed because of drag changes but this has nothing to do with general wind direction. Gusts obviously have an affect but that's a different issue. The only time wind speed and direction becomes relevant is when you're flying close enough to the ground for the topography to affect the wind but that's really no different to gusting so still a different issue.

[error414]

I tested auto speed today. I'm happy how it works. Tested in strong wind, 8 - 9m/s, guts up to 13m/s

https://youtu.be/ClvGF0pV3Sw?si=RAIhrPtX7PaOMmhB&t=93

set nav_fw_auto_speed_p = 40
set nav_fw_auto_speed_i = 20
set nav_fw_auto_speed_d = 0

I use dedicated pitot tupe from flyingrc.

BTW: this PR is not posible use with PR, #11553 , there is the conflight.

[breadoven]

Min speed default increased to 14m/s. This is good to merge now.

Don't know why docs update is failing given settings.md was updated after setting change. @sensei-hacker ?

[rts18]

@breadoven I've been using this feature continually with no issues.
I used it on a WP mission last week and it worked flawlessly.

I have a request. Would you be willing to add the 3D speed based target to the mission planner? I figure that the fw_auto_speed_max_speed and fw_auto_speed_min_speed would apply boundaries to limit the entry.

When I've run long missions, I thought it would be useful to increase the ground speed, when there is a greater distance between certain waypoints. Then slow the ground speed down to a more conservative value when approaching the POI.

One could raise the case for this entry to also use an air speed based target. Although I don't think that would have any benefit due to waypoints being ground based markers. With the main advantage of this entry being to allow the plane to make it to the next waypoint in a shorter period of time.

[breadoven]

@breadoven I've been using this feature continually with no issues. I used it on a WP mission last week and it worked flawlessly.

I have a request. Would you be willing to add the 3D speed based target to the mission planner? I figure that the fw_auto_speed_max_speed and fw_auto_speed_min_speed would apply boundaries to limit the entry.

Shouldn't be difficult to do. At the moment the WP speed settings are generally available but only applied for Multirotor use. It should be easy enough to apply them to fixed wing speed control as well. I'll have a look at it.