Fixed wing attitude stabilisation mode

[breadoven]

Provides an Attitude Hold mode for fixed wing, called ANGLE HOLD. It is based on Angle mode but sets the stick centred attitude datum to the current attitude at the time the stick was centred rather than the normal "level" datum used by Angle mode (0 degs pitch/roll). Control when the stick is NOT centred behaves the same as Angle mode with the same max bank angle limits and pitch/roll axis rate control method. So when the stick is centred the only difference between this mode and Angle mode is that it uses a different centre stick pitch/roll datum, a datum that is updated every time the stick is moved and returned back to centre.

It also possible to use this mode during Course Hold and Altitude Hold modes when it allows pitch and roll respectively to be adjusted and held with stick centre. This only works when the ANGLE HOLD mode switch is selected. Nav max pitch limits are used when pitch hold is active rather than the normal Angle limits.

System messages are show to indicate if the plane is level (ANGLE HOLD pitch and roll setpoint angles are level) and also if ANGLE HOLD Pitch hold is active during Course Hold or ANGLE HOLD Roll hold is active during Altitude Hold.

Angle, Horizon selection in fc_core.c has been refactored and Flight mode change beeper behaviour has been reworked. Rather than beep every time a mode is changed the overall flight mode status is instead checked every Rx update with a single beep produced if flight modes have changed since the previous Rx update.

Tested OK on HITL sim and also by flight test.

Related to discussion #9269.

[Jetrell]

Provides an Attitude Hold mode for fixed wing. Similar to Angle mode but holds the current attitude when the pitch/roll stick is centred. Configured so that Angle and Horizon modes have priority over Attitude hold.

Can you please provide a little more info of its operation ?

And why is SENSOR_ACC only required for Angle ?

ANGLE and HORIZON do work differently,. With ANGLE using max_angle_inclination_rll and max_angle_inclination_pit to control the maximum angle of incline allowed. But those value also influence the rate of control response from the stick input.
i.e. Lower inclination values hardly allow any response to stick movement at all. And higher values allow a faster rate of response.
While HORIZON mode uses fw_d_level as type of Control Derivative, to override the Level PI controller and provide rate authority like that of ACRO mode.

[breadoven]

Can you please provide a little more info of its operation ?

Pretty simple really. When selected ON the current attitude will be held if the pitch/roll stick is centred. Pitch and Roll can be adjusted in the same was as Angle up to the bank limits. When the stick is released the current attitude will be held. There's no stall prevention, you need to actively control things the same way you would in ACRO.

And why is SENSOR_ACC only required for Angle ?

ANGLE and HORIZON do work differently,. With ANGLE using max_angle_inclination_rll and max_angle_inclination_pit to control the maximum angle of incline allowed. But those value also influence the rate of control response from the stick input. i.e. Lower inclination values hardly allow any response to stick movement at all. And higher values allow a faster rate of response. While HORIZON mode uses fw_d_level as type of Control Derivative, to override the Level PI controller and provide rate authority like that of ACRO mode.

But Horizon is still a self levelling mode which it can't do without an Accelerometer/Gyro.

[Jetrell]

Pitch and Roll can be adjusted in the same was as Angle up to the bank limits.

Most users set max_angle_inclination to around 85, the limit. To provide the best stick control over ANGLE mode, for reasons I mention above.

When the stick is released the current attitude will be held. There's no stall prevention, you need to actively control things the same way you would in ACRO.

Then what happens if the stick is moved farther than required. And it ends up being at some wild angle, like 70degs.. Does this mean the user has to quickly fumble around to turn OFF the function, to disable that held angle ?
If so, that could be a bit of a worry, without some quick means to override it, especially close to the ground... My first instinct would be to push the stick the opposite direction, rather than switch out of the mode.

But Horizon is still a self levelling mode which it can't do without an Accelerometer/Gyro.

Very true.. It seems odd there is no reference of SENSOR_ACC in Horizon.

[breadoven]

Most users set max_angle_inclination to around 85, the limit. To provide the best stick control over ANGLE mode, for reasons I mention above.

The max is actually 90 degs if you check the setting max_angle_inclination_pit, with roll the same.

Then what happens if the stick is moved farther than required. And it ends up being at some wild angle, like 70degs.. Does this mean the user has to quickly fumble around to turn OFF the function, to disable that held angle ? If so, that could be a bit of a worry, without some quick means to override it, especially close to the ground... My first instinct would be to push the stick the opposite direction, rather than switch out of the mode.

You can't exceed the max bank angle limit by over controlling with the stick. Holding max stick deflection when you're at max bank angle limit just sees that max allowed bank angle held, exactly the same as Angle. Even if you select the mode ON when attitude angles exceed the bank angle limits all that happens is the mode will bring the attitude back to and control to the max bank angle limits, i.e. the maximum attitude hold angles are constrained to the max_angle_inclination limits. And you wouldn't need to turn the mode off to recover, just move the stick to correct the attitude back to where you want it. It's pretty care free other than obviously the fact you can put it in an attitude that causes the airspeed to drop too low.

[breadoven]

Ah there is a problem with changing setting Angle etc in fc_core.c ... makes the flight mode change beeper go nuts. Didn't notice it on HITL because the beeper was muted. Needs fixing ...

In fact it seems nuts setting a beeper every time you enable or disable a flight mode. Would make more sense to simply update the flight mode status every Rx update and sound a beeper once if it's changed. Most of the time you never hear these beeps in flight ... so the current method just adds complication for little benefit.

[Jetrell]

I did some testing.. And I like how the stick control of attitude adjust works. With the general concept working fine.
Although I have some feedback on this mode... Please don't take anything I say as criticism towards your work... But rather from my past experience of using attitude controllers of many types.

I'm not sure if you've flight tested it yet. Or how it performed in the HITL ?
Today's conditions displayed some wind. And the test airplane was of agile performance with increased throw limits, and fw_iterm_throw_limit also increased. With more than adequate throttle applied for the commanded attitude.

Its characteristics are very similar to cranking up the I-term in Acro/Airmode.. With the general performance working fine, but displaying attitude drift within a short period of time, when both axis's have some attitude offset applied.

It appears to work as just a gravity vector offset, and lacks the ability to calculate and integrate the transfer of error from one axis to another as an AVCS does.
And also lacks the ability to assist navigation modes. Of which many FPV users may find helpful. i.e. A gradual turn angle or a fixed climb angle , as the the craft fly's from Point A to point B over a distance.

Being that this mode would primarily be used to assist Climbs or Turns.. I imagine allowing it to work with the GPS heading controller, may assist its operation. And because it doesn't work as a 3D gyro attitude controller.. I can't see any reason to have its max inclination set point greater than 30degs on both axis's.
And just thinking out loud here - Having the Pitch attitude adjustment being assisted by auto throttle. And the Roll attitude by fw_turn_assist_pitch, may help beginners.. But I'm aware that would be a lot of extra work.. But with anything less, I'd honestly consider the mode a risky for most users, and not something advanced users would likely bother with in its present form.
Not meaning to sound negative. Its just my honest assessment.

[breadoven]

It sounds like you're expecting too much from this @Jetrell. As I see it using this mode is similar to using ACRO when flying sedately but without the attitude drift you see with ACRO, especially in roll, and it really needs to be used like that when it comes to risk, i.e. you can't fly in ACRO, point the nose at the sky and expect the plane to not stall so you shouldn't expect this to behave any differently. The pilot needs to actively be in control but there is the benefit that if you release the sticks the plane will maintain attitude stability so long as airspeed is high enough. ACRO can't do this for long without drifting in my experience so in fact this mode is better for beginners if anything, it's more care free, not as care free as ANGLE perhaps but IMO ANGLE is a recovery mode that is otherwise fairly useless for free flying.

Have to admit I haven't tested it in real flight, only in HITL which has it's limitations but should reasonably well simulate things like this. I didn't see any drift testing in HITL and in fact how would you know there's drift when you don't know what the target roll/pitch angles were when you released the stick ?. It has a target roll or pitch angle to maintain so there could be an offset from those targets if the I term doesn't do its job but it can only be a limited offset, not something that continuously drifts like ACRO does. At worst I would expect it to oscillate around the target pitch/roll angles if the I term was too high. It shouldn't really behave much differently to normal ANGLE given the only difference is it's holding some roll/pitch angle target > 0 rather than 0 as ANGLE does. Also don't forget that all the NAV modes navigate using ANGLE with a non 0 roll/pitch angle to maintain. ATTIMODE essentially does the same thing with fixed roll/pitch ANGLE targets set when the stick is centred. So if you have issues with ATTIMODE mode drifting you'll also have issues with the NAV modes I'd have thought.

I tested it again in HITL (raining again in the UK as usual) with a load of wind and X-Plane's weird turbulence turned on and it behaved as expected. Got thrown around a lot but tried to maintain the attitude that was set when the stick was released. There was no increasing drift because that isn't really possible given how it works, the P term will limit it at worst.

I agree about integrating it in with NAV modes in some way but that's really nothing more than extending what it currently does through control logic. Integrating it in with Course Hold would be useful if it was limited to pitch only to allow manual climb angle control.

I'll be interested to see how this performs next time I get the chance to test for real. See if HITL is telling porkies.

[Jetrell]

how would you know there's drift when you don't know what the target roll/pitch angles were when you released the stick ?

When in a sustained climb. e.g. 20degrees... I started fine tuning the roll, to get it as close to zero as possible (it was very touchy. Perhaps running the pitch/roll stick release target attitude through a PT1 filter, would also help provide a cleaner attitude hold set point in windy conditions ? )
Then once at the attitude I required on both axis's, I let the climb continue. (with an adequate amount of throttle, I won't say what the altitude got to.)
I was basing attitude on geographic marker points, over a good distance, and cross referencing it with COG and compass heading and the aircraft's pitch/roll.

A long gradual turn on the roll axis, had less yaw and pitch drift. While a sustained climb suffered more roll and yaw drift.. With the condition being worse if the climb angle was increased.
The AHRS uses GPS and supposedly the magnetometer as well to correct IMU drift.. But its one thing to make ACC drift correction on the roll axis. And another to work out corrections, based on pitch offset to the gravity vector in a sustained climb, IF the climb rate is close to 1G.... And with obvious magnetic deviation also likely to occur.

[sensei-hacker]

-- Edit ---

I think I figured out what you're going for.
If Acro mode had zero drift at stick center, would that cover this use case?

That is to say, suppose that with the stick centered attitude stayed rock solid, otherwise moving the sticks changes the attitude. Would that cover it?

That is, of course, the definition for acro, the contract between pilot and INAV - centered stick just isn't perfect yet. If that would cover it, I'll toss something over for you to consider and test if you want to. I think we can make stick center perfect in acro without drift pretty easily. Thereby covering this case without a new mode.

-- End edit --

This is a little unclear to me.

holds the current attitude when the pitch/roll stick is centred

So far that's rate mode aka acro, so that makes sense so far.

Pitch and Roll can be adjusted in the same was as Angle up to the bank limits.

This seems to directly contradict the first sentence. "adjust the same as Angle" would mean that to adjust for level flight, you would center the stick. So this statement and the first can't both be true, can they?

Should that say "adjusted the same as acro"? I guess not, because then the new mode would be the same as acro.

Yeah I could read the code, but we can't tell users to read the code - we have to be able to tell them in English what it does. And I don't think the English description above can be quite correct, because the two sentences are contradictory. Perhaps the simplest way would be to fill in the blank here:

Mode name	Sticks control
Manual	Servo position
Acro (rate)	Rate of bank/pitch
Angle	Attitude (angle of aircraft)
Cruise	Change of flight direction
New Mode	???????????????????

[Jetrell]

Someone mentioned Horizon as "the devil's mode".

@sensei-hacker Sorry.. I deleted it.. I thought it might have side tracked the topic.

But you have brought up some good points.. I really think Attitude mode has potential. And I'm always grateful to Breadoven for his work.
Although, as you stated with horizon mode. If people get confused with it.. Then ATTI mode certainly needs to be very well explained. To make it as user friendly as possible..
INAV has plenty of amateurs pilots, as we see on Discord. That this mode would absolutely bring undone in it present state. Especially if their airplane is prone to tip stall.

I agree about integrating it in with NAV modes in some way but that's really nothing more than extending what it currently does through control logic. Integrating it in with Course Hold would be useful if it was limited to pitch only to allow manual climb angle control.

Course Hold mode with pitch attitude control only, and using Pitch2Thr climb assistance would be safe and useful.
And Altitude Hold mode with roll attitude control only, would also be great for long slow banking turns.
But its hard to have the both in one.
And being that this mode isn't a 3D attitude controller.. There is no universe in which I can see it requiring more than 30degrees pitch or roll, separate from max_angle_inclination.

[sensei-hacker]

I thought of another way to ask, so maybe I can have a clearer understanding and be able to explain this to people on Discord:

If I'm currently at 30° left bank in this mode, how do I level out?

"Like angle mode" would mean I level out by centering the stick. But you said centering the stick holds the current angle. So is it impossible to level out in this mode?

Reading this, to my dumb brain it sounds like the explanation to users would be:

"It's angle mode, except you aren't allowed to level out. Centering the stick will keep the current angle."

I'm sure I'm not getting that right. I'm sure there is a way to level out, that it's not "angle mode except you can't fly level". I'm not understanding how you would level out if you're currently at 30° bank though, from the description.

[breadoven]

@Jetrell It sounds like the drift you're seeing is a consequence of the limitations of the INAV AHRS rather than anything to do with this mode. The mode will simply try and hold the set attitude. If the AHRS attitude datum is shifting then so will everything else including ACRO and all the NAV modes. I'm not sure HITL would show such drift especially if it's subtle because it relies on simulated inputs to the AHRS not inputs from the actual sensors on the test plane. So this needs more actual testing to see if perhaps this particular mode causes issues for the AHRS. Not really sure it would unless it's tuned to behave best at level datums.

@sensei-hacker I updated the description. Hopefully it might now be clearer what this does. As for your table above ... it missed one thing ... reference datum used which is what this mode is about. And yes the issue is ACRO drifts. Is it possible to fix it based on using rates ... I'm guessing not looking at how it works, IMO the reference it uses simply isn't solid enough to be used reliably over a period of time, too floaty and easily upset by disturbances. The benefit of ATTIHOLD is it uses a more solid reference so is much less likely to drift (AHRS issues aside because that will screw up everything regardless).

If I'm currently at 30° left bank in this mode, how do I level out?

By correcting with the stick. When the stick is re-centred the new current attitude will be remembered and maintained until the stick is used to adjust the attitude again.

[sensei-hacker]

And yes the issue is ACRO drifts. Is it possible to fix it based on using rates ... I'm guessing not looking at how it works, IMO the reference it uses simply isn't solid enough to be used reliably over a period of time,

In that case, it appears there is a simple solution that will be very clear and easy for users to understand. While accomplishing what you want - drift-free attitude hold. At least that's what I'm understanding you want - the attitude is locked, it doesn't change when stick is centered. My thought is to do it almost the same as this proposal, just with the conditional inverted.

Consider rate mode. At stick center the attitude isn't supposed to change. It does drift, it's not supposed to. So how about the improvement that when the stick is centered, it actually doesn't drift? That's what's expected anyway, what rate mode is supposed to do. How to accomplish that? Just by inverting the if condition. If stick is centered, lock to that the angle. (Which is the same behavior as locking to zero rotate, just more accurately). When not centered, move just like rate mode always does.

I think that accomplishes what your objective likely is, by having the rate mode do what it's already supposed to do - maintain the same attitude when the stick is centered.

Vs the idea of "the mode behaves one way, except in the special case of stick center, where it behaves completely differently".

So my proposal would be to add to rate mode "if stick is centered, actually provide zero rate as expected - by checking the angle. That gives you attitude lock - by making rate mode behave as already documented and expected. We just internally implement "zero rate" as "maintain angle".

So inverting the condition to make that happen:

function rate mode() {
  if (stick == centered) {
    // At center stick, maintain current atti
   If (! hasTargetAngle) {
     target_atti = current_atti
   }
   HoldTargetAngle(target_atti)

  } else {
   SetTargetRate()
   hasTargetAngle = false
  }
}

Would that accomplish your objective of having attitude lock? It wouldn't change any defined behavior. It would just be making rate mode hold better at center stick; it would eliminate drift.

[breadoven]

@sensei-hacker The problem with your proposal is you could end up trying to hold attitudes that are unrealistic, too high. In a previous iteration I had things working without the hard stop bank angle limitation. Instead you could exceed the limit much like Horizon but the attitude would then still be held when it came back down within the bank angle limits. However, I decided this wasn't practical and would have definitely been confusing. So I opted instead to simply stick with the way Angle works, limited to the max bank angles.

If you were to do something based on ACRO then it would need to only be active below certain attitude limits which I guess you could do given the user wouldn't know it was attitude controlled not rate controlled ... but then that would mean ACRO wasn't actually ACRO any more wouldn't it ... it would still be some other "rogue" mode.

[sensei-hacker]

It occurs to me that the code in the PR can't reduce drift at all, can it? It HAS to drift exactly as much as rate mode does at center stick, because at center stick it is rate mode. So it will drift at center stick just like pure rate mode does.

I'll make a PR that eliminates the drift in rate mode.

[sensei-hacker]

If you were to do something based on ACRO then it would need to only be active below certain attitude limits

Sounds great. At center stick, use whichever sensor(s) best make acro do what acro is supposed to do, what it's documented to do.

but then that would mean ACRO wasn't actually ACRO any more wouldn't it

I'm not sure what you mean here. It would behave exactly the same way it always has - just without the accidental, uncommanded drift from imperfect sensors. Exactly the same as it works today and has always worked, with a high quality gyro. Just by using the accelerometer to assist the gyro when the rate is too small for the gyro to measure accurately. It's exactly rate controlled, no change to that at all. We just measure the rate more accurately, by referencing the accelerometer for long term changes when zero rate is requested. Exactly the same behavior. Just more accurate. Purely making a cheap gyro work more like a laser gyro, an accurate gyro.

My proposal is to keep the rate / acro behavior exactly, perfectly the same as it always has been. Just measure the rate more accurately when the pilot asks for 0° per second.

[breadoven]

Stick centre has nothing to do with what mode it uses. It's in ACRO, rate mode, unless ANGLE, HORIZON or ATTIMODE is active in which case they override the rates set by ACRO. So ANGLE, HORIZON and ATTIMODE are controlling based on Angular error to a set angular target, unlike ACRO that is simply trying to keep the rate error at 0.

[sensei-hacker]

Stick centre has nothing to do with what mode it uses.

I re-read your code and you're right. I was wrong.
I was thinking based on the behavioral description rather than the code implementation.

This first proposal behaves like rate mode when the stick is centered, but is implemented like angle mode. (The defined behavior of rate mode is attitude hold when stick is centered).

Which I think is a genius idea. Just would be better flipped. Your attitude hold is great. It just happens to be you had a great idea for how to implement the behavior that is defined for rate mode. When stick is centered, hold the current attitude.

Since I spend more time explaining INAV to users than coding it, I tend to think in terms of how the behavior is defined, rather than how it's implemented. You probably spend more time coding than explaining.

We tell the users that if you center the stick in acro mode, it will try to have zero rate, it will try to hold the current attitude with zero change. Aka atttihold.

[sensei-hacker]

The problem with your proposal is you could end up trying to hold attitudes that are unrealistic, too high.

I agree we shouldn't try to hold an attitude that we can't hold.

That problem applies EXACTLY as much with this PR, right? If the user centers the stick in ATTIMODE, therefore requesting to hold an unrealistic attitude, you still have exactly the same problem.

What normally happens when you center the stick at an extreme angle in rate mode? I absolutely agree we shouldn't change that, unless perhaps the behavior in such a case is clearly broken currently
Just thinking we could try to do what we tell users we try to do - if you request zero rate (by centering the stick), that's attitude hold, we say. So do that if we can.

Which probably means that the implementation of zero rate can use accelerometer assistance only at reasonable angles.

I notice the exact same concern applies just as much to the implementation in this PR. If you can't hold 135°, you can't hold 135°, right?
It doesn't matter what the switch settings are - if INAV can't hold some extreme attitude, it can't hold that attitude. So I don't think that's a difference between the two ways of requesting "maintain attitude". Whether the pilot requests maintain attitude via the existing rate mode (0 rate) or with some new mode, or with a more accurate rate mode, any attitude we can't hold is one we can't hold. That's a true fact. Not a difference between the implementations - it's always true.

[Jetrell]

The words RATE, ANGLE and ATTITUDE are rather loosely used in the RC hobby. And can be misunderstood, depending on the function they are applied to.
There are two different types of gyro stabilization controllers. I think it may be helpful to mention them..

• RATE type. Which is obviously the most common.. It tries to dampen the RATE of unwanted error, that differs from the desired target. But in itself, a rate type controller only reacts to rate of change. Which is why the Proportional component of its controller does most of its work.

• Heading/Attitude LOCK type. Does not just react to change. But also fights to prevent angular drift from the target in the first place.. This type of controller uses the Integral component to do most of the work. With the p-term only reacting to rapid change.
  A standard rate controller only uses i-term to mildly dampen long term error.. While the i-term on a Lock controller is allowed to grow exponentially in order to provide extreme output correction to resist angular offset change. And also suppresses, reduces or clears the growth of the Integral, when counter-force perturbations are applied to the sensor.. Providing a means for the Integral to work much faster than it would on a standard rate controller.

[MrD-RC]

but then that would mean ACRO wasn't actually ACRO any more wouldn't it

I'm not sure what you mean here. It would behave exactly the same way it always has - just without the accidental, uncommanded drift from imperfect sensors. Exactly the same as it works today and has always worked, with a high quality gyro. Just by using the accelerometer to assist the gyro when the rate is too small for the gyro to measure accurately. It's exactly rate controlled, no change to that at all. We just measure the rate more accurately, by referencing the accelerometer for long term changes when zero rate is requested. Exactly the same behavior. Just more accurate. Purely making a cheap gyro work more like a laser gyro, an accurate gyro.

My proposal is to keep the rate / acro behavior exactly, perfectly the same as it always has been. Just measure the rate more accurately when the pilot asks for 0° per second.

Because acro is not supposed to hold attitude. It’s just supposed to be manual with wind stabilisation. Manual would not hold attitude.

[sensei-hacker]

There are two different types of gyro stabilization controllers. I think it may be helpful to mention them..

Can you comment on how the two might best be used when the user wants the RATE to be zero, when they want the attitude to not change?

These are of course exactly the same thing - zero rate of change means stay there. Which might be better for this case, or how might they be combined?

[breadoven]

ACRO is a stabilised mode based on pitch/roll rate control, MANUAL has no stabilisation at all it just controls the servos directly as if the FC didn't exist, hence the old name passthrough. So they're not really comparable. With stick centred ACRO simply tries to hold the pitch/roll axis rates at 0. If it did this perfectly it would effectively hold attitude which is does actually do for a while before the errors start to build up and it drifts.

I never really wanted a new mode for this so in many ways it would be easier to compromise by allowing attitude hold to function in ACRO when the attitude is within certain limits, the limits where you might want ACRO to reliably hold a set attitude constantly, e.g. a long climb or a constant bank turn. All the user will see is ACRO working better by holding the attitude it had when the stick was centred which was really the aim of this all along. This behaviour could also be made optional with a setting if people want to keep ACRO behaviour unchanged as it is now.

[Jetrell]

I only had the time for one quick flight.. Nice additions.
It also seems to hold better now with little drift, as I mentioned earlier, when the stabilization controller i-term is set lower.

What is your opinion of the effect Continuous servo auto trim may have on this mode ?

[breadoven]

Looking at Continuous servo auto trim it seems to be active when roll/pitch are within 5 degs and during any flight mode other than Manual. There are also rotational rate limits. So I guess it would be active if ATTI mode is active with roll/pitch < 5 degs and if rotation rates are low enough, but this should be no different to ACRO. Not sure how it would affect things, surely just shifts the servo mid point but shouldn't affect overall flight mode behaviour ?

I don't really use any of these auto trim functions so haven't tested it. I prefer to trim mechanically and leave it at that. Was the drifting plane using auto trim ? Could always disable auto trim for ATTI mode if it seems to cause problems, same as MANUAL mode.

[Jetrell]

Was the drifting plane using auto trim ?

Yes they were.. And I have turned it off in my last tests. Which is now better.
Continuous servo auto trimuses i-term error to compute servo centering.

I think it maybe wise to prevent any of these trim modes from working with Attitude mode.

Continuous servo auto trim
Servo auto trim mode
Auto level trim mode
Auto tune.

[breadoven]

Was the drifting plane using auto trim ?

Yes they were.. And I have turned it off in my last tests. Which is now better. Continuous servo auto trimuses i-term error to compute servo centering.

I think it maybe wise to prevent any of these trim modes from working with Attitude mode.

Continuous servo auto trim Servo auto trim mode Auto level trim mode Auto tune.

I need to check the other modes but I'm not sure continuous servo auto trim would have caused the drifting problem you had before because surely the bank angles were > 5 degs, meaning it wouldn't have been active.

I did wonder what this mode would do on a multirotor. Essentially it should just hold the roll and pitch angles, which coupled with Alt Hold would give a form of ATTI cruise mode. As it is now if you enable Alt Hold it would allow the multirotor to fly sideways with stick centre but if the axis was changed to pitch you would have ATTI cruise in the forward direction. You'd also need to enable ANGLE because it's not auto enabled for AltHold on a multirotor as it stands. Might be worth testing and perhaps this would work better than the current speed limited Cruise mode since it would avoid the fluctuating speed oscillation issue.

[Jetrell]

surely the bank angles were > 5 degs, meaning it wouldn't have been active.

Certainly, the bank angles were greater than 5degs.. Although I'm not exactly sure how zero attitude reference is viewed in this mode. Because its an earth frame offset.
What I am sure of. It was slowly accumulating i-term error under certain banking/climbing conditions.. Being the higher the i-term was tuned too, the more pronounced the drift.

Might be worth testing and perhaps this would work better than the current speed limited Cruise mode since it would avoid the fluctuating speed oscillation issue.

That would be nice.

[breadoven]

Were you using Auto level trim mode when testing @Jetrell by any chance or have fixedWingLevelTrim set to a non 0 value ? I've noticed there is an issue with this. fixedWingLevelTrim needs to be taken account of by Attimode but more fundamentally Auto level trim mode has a basic bug in it which makes it hard to believe it would ever work as expected, possibly very gradually ... which would cause slow drifting. It uses a dT value for the PID controller but the old time value used to calculate dT is simply missing so rather than dT the PID controller is using current time as far as I can see. I'll do a fix for this ASAP. Also need to sort out the issue related to fixedWingLevelTrim for this PR.

[Jetrell]

Yes they're all non zero values... Nice find.
I've heard many people saying they've found AutoLevelTrim very inadequate of late.. I'd been trimming it will the OSD/Adj inflight tuning.
This would explain the reason for both issues.

[DzikuVx]

That's a cool feature. But I think we should find out a more distinctive name for it. I have a feeling pilots will be messing up names.

Maybe something like ANGLE LOCK ?

[breadoven]

That's a cool feature. But I think we should find out a more distinctive name for it. I have a feeling pilots will be messing up names.

Maybe something like ANGLE LOCK ?

Yes it did occur to me it might get confused with Altitude hold ?

ANGLE LOCK should be OK. Mode indication = ALOK or ALOC rather than ATTI ?

This should be OK to merge now, just need to fix a minor issue with the ATTI system message being shown when Manual mode is active.

Not really a beginners mode but useful if you want to hold a non level flight path for a while hands free.

[sensei-hacker]

There has been a LOT of discussion of exactly what this should do. I remember a few things that were discussed and don't want to get confused between something that was discussed but not implemented vs what was actually implemented.

Breadoven, ss this an accurate way to explain the behavior to users:

When you engage angle lock, it will remember that angle (attitude) and maintain that attitude when the sticks are centered. For example, if you want to do hands-free climb, start your climb, then engage angle lock. It will continue to climb at the same pitch when you let go of the sticks.

If not, would you mind clarifying how it ended up with a one or two sentence statement of exactly what behavior you ended up implementing? (I'm thinking in terms of user-visible behavior, as opposed to the internal mechanism of how it does it.)

[breadoven]

I changed the mode name to ANGLE HOLD in the end rather than lock since this is consistent with the other "Hold" modes used by INAV. The OSD flymode name is currently AHLD but I'm thinking ANGH might be better, ANGL(evel) and ANGH(old) as it were. Other than these tweaks, it should be OK to merge now.

@sensei-hacker

When you engage angle lock, it will remember that angle (attitude) and maintain that attitude when the sticks are centered. For example, if you want to do hands-free climb, start your climb, then engage angle lock. It will continue to climb at the same pitch when you let go of the sticks.

That largely describes how it works. However, it's not limited to only activating it at the desired attitude you happen to want to capture, rather it can be activated like the other stabilisation modes such as normal ANGLE and it will behave the same way in terms of manoeuvring using the stick with the only difference being that it will hold the current attitude when you release the stick rather than self level.

It also works with COURSE HOLD and ALT HOLD modes where it will hold a single axis, Pitch and Roll respectively, when the stick is centred. In that case you need to select the ANGLE HOLD mode switch together with the COURSE HOLD or ALT HOLD, it's not auto enabled. It also uses the NAV bank angle limits with these Nav modes rather than the general ANGLE bank angle limit.

[Sibre3]

@breadoven I've been using this useful mode.
Presently it requires the throttle to be adjusted by the operator, according to the climb or dive angle. As shown here. https://github.com/iNavFlight/inav/wiki/Modes#angle-hold-fw
However, I have an idea to reduce some risk.
Since the climb and dive angle is constrained by the navigation angle limits and not max_angle_inclination limits. I thought it may be helpful to enable auto throttle control over this mode when Angle Hold + Course Hold are turned on together?
This should permit pitch2throttle to increase the throttle automatically when a climb is commanded, to reduce the chance of a stall.
Would you be interested in adding this improvement?