Use 1500ms instead of "Throttle MID" for althold in "MID_STIK" mode.

[and-sh]

trafficstars

Current Behavior

Throttle MID is used for althold neutral position. This is kinda inconvenient because I set it about 0.2 for easy hovering.

Desired Behavior

Use 1500ms for neutral position.

Suggested Solution

Use precisely 1500ms for neutral position.

Who does this impact? Who is this for?

For people using drones that have a hovering throttle different from 1500ms.

Additional context

It is not very correct to set up the exp on the radio.

[sensei-hacker]

Do you only ever use althold/Poshold? Or do you switch between modes?

If you switch between modes, you almost surely want hover set to "stick", not mid.

(And if you don't switch between modes, I don't see any reason you would have changed throttle mid "for easy hovering".)

[and-sh]

I mostly fly in acro. I need poshold for pauses to adjust glasses or shoo away a mosquito and for landing. I have hover throttle 1230ms. So the ascent speed is controlled well. The descent speed is controlled very poorly. In addition, below a certain throttle position it simply falls like a stone. Now I have found the next bypass. I add much throttle and quickly switch to althold.

[sensei-hacker]

I'm not sure if I'm following what you're saying here:

So the ascent speed is controlled well. The descent speed is controlled very poorly.

The normal process to switch into althold / poshold for a minute is to put the aircraft roughly into a hover, then engage althold. It will maintain the same altitude until you move the stick. This is done by setting the stick mode "stick", not mid.

Mid: maintain altitude if the stick is exactly at 1500

Stick: maintain altitude as long as and-sh doesn't move the stick

[and-sh]

Mid: maintain altitude if the stick is exactly at 1500

This is not true. In my setup MID this is about 1200. That's the point of issue

[sensei-hacker]

Mid: maintain altitude if the stick is exactly at 1500

This is not true. In my setup MID this is about 1200. That's the point of issue

Sure, but if you just leave it "stick" there is no issue. The point of "mid" is for people who want to pretend it's DJI and never use acro mode or angle or anything else - for permanent althold.

[breadoven]

Mid: maintain altitude if the stick is exactly at 1500

This is not true. In my setup MID this is about 1200. That's the point of issue

MID is based on idle throttle, max throttle (hard coded at 2000 for MR) and thr_mid setting (50% default). So it should be close to 1500 but not 1200 unless you've got some odd settings for idle throttle and thr_mid.

And I agree that control when hover throttle is low, e.g. 1250, is not great using STICK or HOVER, because the control resolution when descending is worse than when ascending. Hard to see what you can do to improve that issue though.

Edit: just noticed you do have thr_mid set to 20% which explains things. Why this setting to aid hovering though ?

[and-sh]

Well, yes, that's right. Why not just put 1500 here? Instead of calculating this. 1500 is the middle for most radios

Edit: Sorry, that was the wrong picture

[and-sh]

Edit: just noticed you do have thr_mid set to 20% which explains things. Why this setting to aid hovering though ?

Yep, this really helps to maintain the altitude accurately. I got used to adjusting it like this a long time ago

[breadoven]

Well if you did want to use 1500 you would add it as an additional option rather than using the HOVER option. It did occur to me before though that it would be useful to have another Althold throttle option that simply allows you to set whatever value you want, such as 1500. This would be the easiest option here and should be possible without adding another setting.

[and-sh]

Sorry, that was the wrong picture, now it's correct.

[and-sh]

another Althold throttle option There are indeed 3 options. MID_STICK is called that, but it doesn't lead to 1500. In fact, it duplicates HOVER.

[breadoven]

HOVER uses the nav_mc_hover_thr setting so not the same as MID_STICK which should be close to 1500.

[and-sh]

Mid stick uses thr_mid. which defines the point from which the exponent is counted. It is most logical to put something like hover throttle there. Therefore, in general, these settings are equivalent At least it is so in my case.

[sensei-hacker]

Therefore, in general, these settings are equivalent At least it is so in my case.

I understand the logic of your case and it kinda makes sense. And of the several thousand pilots I've spoken to about various issues they were having, you are the only one I've seen do that. I've looked at a lot of diffs, and I don't think I've ever seen that before. So I would not say that's what people generally do. Even if there is a certain logic behind it.

[and-sh]

So this is misunderstanding. Cleanflight made this settings especially for me. You borrowed they to use as a constants. Just return they to me and use constants as constants. Nobody other will notice this. CLFL_220 apr 18.json

[MrD-RC]

So this is misunderstanding. Cleanflight made this settings especially for me. You borrowed they to use as a constants. Just return they to me and use constants as constants. Nobody other will notice this.

CLFL_220 apr 18.json

INAV isn't CleanFlight. Just because a project is forked from another. Don't expect it to be the same. Especially after all this time. INAV works how INAV works. Not how CleanFlight or BetaFlight does.

[and-sh]

Okay, if you want something done right, do it yourself.

[mmosca]

Well, yes, that's right. Why not just put 1500 here? Instead of calculating this. 1500 is the middle for most radios

Edit: Sorry, that was the wrong picture

Not all radio systems have 1500 as mid point. Actually, 1520 is probably historically the correct mid point.

[and-sh]

then formally there are 2 errors here 1 use of variables intended for correction of the throttle curve in althold 2 the result of calculations of the middle position is not connected with the real position of the stick and will never give 1500 or 1520. so if your throttle stick is spring-loaded there will always be drift. in addition the result depends on the idle so it will change with different settings.

[Jetrell]

@and-sh There is this setting that can help in that case. alt_hold_deadband

[and-sh]

It is better to correct the cause and not the effect

[b14ckyy]

Lets keep this open as this is actually a interesting use case/topic for future enhancements.

As I just start with quads again I have a similar issue with the STICK option for altitude hold. Resolution to descent is very low and I want to use nav modes and acro modes equally on that build.

One option that comes to my mind, would be a althold blocker for the mid_stick option until the stick actually reaches the middle position. For example: You hover in angle or acro mode at 1200 stick position. You enable althold with MID_STICK enabled. Instead of descending, you ignore the stick position and just hover in place. Throttle stick needs to be moved to neutral/center at least once, and THEN the altitude control is enabled to climb and descent on demand.

It would still create a throttle punch when switching althold off though. That could also be solved by the same procedure in reverse. Disable althold/poshold only when throttle stick is back to hover throttle at least once. Not sure though if I miss some safety issues here (possible short drop).

[and-sh]

This is too complicated. I guess delay about 0.5S will be enough in both cases. It allow you to set stick to desired position

[b14ckyy]

Not a fan of delays of any kind for control. There might be reasons where fast reaction is necessary and then you don't want to block controls in any way. Imagine a beginner flies acro and loses orientation and wants to use poshold as a panic switch. 0.5s can make the difference for a safe auto-recovery or a hole in the ground.

[and-sh]

This is not a problem. The copter is in post-hold mode while waiting. The delay needs to be adjustable or disabled, since when debugging the PID, you need to quickly switch between modes. You can add an override if the throttle is low or high, cancel the delay. The delay is only needed for throttle. For experienced pilots it can be very low. This is just improvisation, the simpler the device, the more reliable it is.

There is one more problem in althold. Below some throttle descend speed substantially higher than Max. Alt-hold climb rate. It's very noticeable when the mid is low. Nor sure 100%, need more research.

[b14ckyy]

IF we implement such a feature as I described above, we do it properly and not half baked. ;)

regarding your althold speed issue, I have not noticed that but I am also not very experienced in INAV Quad navigation. But I will have a look when I re-maiden my 7" after the FC swap.

[and-sh]

This will be great

[and-sh]

Work fine, but 1500 far from center. I guess this is due to iddle and expo in RCcommand.

[sensei-hacker]

This is too complicated. I guess delay about 0.5S will be enough in both cases. It allow you to set stick to desired position

Agreed, going from "here's how it works" to "here's how it works - except if then this then that, until ..." introduces extra complexity. Unnecessary complexity, oddball exceptions, leads to problems.

IMHO, "here's how it works - except for 500 milliseconds it doesn't do that and instead does something different ..." is another oddball exception. It's the same problem, wearing a different hat. If you want it to work differently, make it work differently. Don't make it ignore the user just for a little while or create other weird exceptions where it doesn't work the way it works.

Extra exceptions and complexity as a band-aid over a problem, without actually addressing the issue directly, is rarely the best course of action.

Better to allow a user to simply set a value. Then it hovers when at that value - always, without weird exceptions that last for a certain number of milliseconds before it changes.

Not that a necessarily think allowing the user to set a value is necessarily a good or bad idea. But it would be better than hacking in weird exceptions where it doesn't actually work as documented.

[and-sh]

regarding your althold speed issue, I have not noticed that but I am also not very experienced in INAV Quad navigation. But I will have a look when I re-maiden my 7" after the FC swap.

I found the cause, but it seems it is not really needed here. https://github.com/iNavFlight/inav/discussions/10576