Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

7.1.2 Plane cruise mode issue with changing altitude #10435

Open
jaroszmm opened this issue Oct 27, 2024 · 28 comments
Open

7.1.2 Plane cruise mode issue with changing altitude #10435

jaroszmm opened this issue Oct 27, 2024 · 28 comments

Comments

@jaroszmm
Copy link

I asked around and it seems this is not my issue only.

Long story short:
IF plane is in cruise mode it randomly reacts to elevator input from radio. If I want to climb I pull the stick and plane goes up normally as it is supposed to.

BUT
If I push the stick down weird things happen. Sometimes it won't dive at all despite pushing the stick fully. Sometimes it takes like 10 seconds to react and dive, and sometimes it does it instantly.

What is worse this can change midflight. So one time I push the stick and plane stays level, other time, during the same flight, plane goes down as it is supposed to.

I already noticed that on two of my planes with 7.1.2, but also I know of at least two people having the same issue. One of them even couldn't climb and only change heading in cruise mode.

If I switch in flight to angle/acro/rth then I can control altitude and pitch normally. This happens only in cruise mode.

Any ideas?

@pmarkiewicz
Copy link

Why this issue is closed? I had exactly same issue today, once inav didn't want to go down.

@MrD-RC
Copy link
Collaborator

MrD-RC commented Oct 27, 2024

@pmarkiewicz It was closed in the Configurator repo because it doesn't belong there.

It is still open here. Which is the correct place for it to be.

@fatbaldmen
Copy link

I believe i had this issue of pitch control being non existent in cruise, yesterday. I tried that model, and another in HITL and all was working just fine. I noticed in HITL that it took around 3-4 seconds before the model went into a shallow climb or dive. I may not have held the pitch stick long enough or at full deflection in the real life flight test. I'll test again, on the model that appeared to fail, when weather is good again.

@b14ckyy
Copy link
Collaborator

b14ckyy commented Oct 28, 2024

A delayed response is normal.
In Cruise mode you control the vertical speed, not the pitch angle of the craft. By default the Vertical speed for manual altitude control is just 2m/s. Additionally the vertical speed controller is very soft to prevent oscillations. It would need manual tuning to operate more responsive but being very responsive is not the focus of cruise mode in the first place.

@jaroszmm What is your manual virtual speed value in Advanced tuning btw? Best would be if you attach a TXT with a diff.

@jaroszmm
Copy link
Author

jaroszmm commented Oct 28, 2024

INAV_7.1.1_cli_BARP_20240729_124008.txt
Here is the DIFF file. Nothing changed since then.

I understand that there can be a delay in response, but can't understand why this delay is so random. For me it always starts climbing the moment I pull the stick but dive is random. Not sure why I need to wait in some planes for the dive to begin. Especially with full stick deflection.

@breadoven
Copy link
Collaborator

A log file would be the easiest way of understanding what it's doing.

@jaroszmm
Copy link
Author

A log file would be the easiest way of understanding what it's doing.

I have one, not sure about gps coordinates going public.

@b14ckyy
Copy link
Collaborator

b14ckyy commented Oct 28, 2024

@breadoven I got the log from him. Will have a look later and share with you later so we can have a look.

@jaroszmm
Copy link
Author

Maybe I also overreact to the behaviour.
Let me get this right:
In cruise mode my elevator stick controls how fast the plane climbs or descents? So if I have it set to max 2m/s then that value is only at full stick deflection, and then 1m/s should be around half of the deflection etc?
That would explain why on small deflection I can barely notice any reaction at first, but also creates a question why full stick deflection creates no reaction at first and then suddenly plane starts descending noticeably.

I'll try to make another flight soon and get another log file if possible. I'm limited by 16MB internal storage on 405WMN on one plane but the second has SD card so it should be easier.

@b14ckyy
Copy link
Collaborator

b14ckyy commented Oct 29, 2024

Yes this is correct. Full stick means the vertical speed is applied based on the setting, so 2m/s at full stick by default.
The VSPEED controller is very soft by default. Additionally fluctuations in the GPS altitude can cause it to react late as well. but try a higher value and see if that changes anything.
in 8.0 an update to the altitude controller was already merged I think that should give a bit better vertical speed control as well. Maybe worth a try.

@Jetrell
Copy link

Jetrell commented Oct 29, 2024

@jaroszmm It also helps if you set
max_angle_inclination_rll = 900
max_angle_inclination_pit = 500
This allows the stick input in Cruise mode (and other Angle based modes) to feel more responsive. Due to full stick deflection no longer being scaled by a bank angle of less than 90 degrees.

@b14ckyy
Copy link
Collaborator

b14ckyy commented Oct 29, 2024

@Jetrell Cruise mode, despite being self leveling, has its pitch angle setpoint controlled by the Altitude controller and roll angle setpoint by the heading control. Raising the angle limits should not make a difference imho. Defaults are 30° up and down that would result in 10m/s on most planes :D

@Jetrell
Copy link

Jetrell commented Oct 30, 2024

Raising the angle limits should not make a difference imho. Defaults are 30° up and down that would result in 10m/s on most planes :D

@b14ckyy I think you missed my point ;-)
It was about the scaling of the pitch and roll sticks.

If roll and pitch bank/tilt angles are set to 30degrees. Full stick deflection only gives you 30 degrees of axis rotation. Which can give the impression that the plane is lacking in control response.
While if they are set to 90 degrees on each axis.. 30 degrees of axis rotation is achieved at only 1/3 stick deflection. Providing a stick feel that allows all the Angle based flight modes too react to stick input in a way that is more reminiscent of Acro mode.

e.g. If you go from flying a plane that has its Acro pitch rate set at 100 deg/s.. Then you fly in Cruse mode with its angle limit set to 30 degrees.. It feels restricted, when you have to apply full stick deflection to make Cruse mode start to climb, and that at a rate less than Acro would with only 1/5 of full stick deflection.

@jaroszmm
Copy link
Author

So you mean with much more scale plane should react quicker but will be limited with max climb and dive rates from navigation tab?

@breadoven
Copy link
Collaborator

Raising the angle limits should not make a difference imho. Defaults are 30° up and down that would result in 10m/s on most planes :D

@b14ckyy I think you missed my point ;-) It was about the scaling of the pitch and roll sticks.

If roll and pitch bank/tilt angles are set to 30degrees. Full stick deflection only gives you 30 degrees of axis rotation. Which can give the impression that the plane is lacking in control response. While if they are set to 90 degrees on each axis.. 30 degrees of axis rotation is achieved at only 1/3 stick deflection. Providing a stick feel that allows all the Angle based flight modes too react to stick input in a way that is more reminiscent of Acro mode.

e.g. If you go from flying a plane that has its Acro pitch rate set at 100 deg/s.. Then you fly in Cruse mode with its angle limit set to 30 degrees.. It feels restricted, when you have to apply full stick deflection to make Cruse mode start to climb, and that at a rate less than Acro would with only 1/5 of full stick deflection.

Doesn't really work that way though for altitude adjustment in Auto modes. Altitude control using the pitch stick during Cruise sets the climb rate with the rate proportional to the stick deflection up to the max climb rate set. The pitch limit max_angle_inclination_pit will (should) only affect things if the required pitch to achieve the demanded climb rate exceeds the max pitch limit at which point the climb rate will be limited by the pitch limit. Setting max_angle_inclination_pit to 90 degs just avoids the pitch limit limiting the climb rate but it doesn't change the behaviour of pitch stick deflection to climb rate demand.

@jaroszmm
Copy link
Author

So if we want more rapid response then we would have to increase a lot climb and dive rates but then limit them with max climb and dive angles. So like set 20m/s dive rate but only 15deg limit for the dive angle.
Still this is a dirty workaround.

@b14ckyy
Copy link
Collaborator

b14ckyy commented Oct 30, 2024

No don't do that as this will mess with the navigation controller.
If you want more responsive altitude changes.

You can try to ramp up the P and D values of the pos_z controller here: https://github.com/iNavFlight/inav/blob/6.1.1/docs/Settings.md#nav_fw_pos_z_d

If you have a clean setup with no pressure changes based on speed, you can ramp up the Baro weight for the altitude controller here:
inav_w_z_baro_p

try a value of 0.6 or 0.8 and see how it changes but also watch how it affects level flight stability with these changes.

@Jetrell
Copy link

Jetrell commented Nov 5, 2024

Doesn't really work that way though for altitude adjustment in Auto modes.

@b14ckyy @breadoven To be honest. I hadn't tested it sense back in INAV 3.0.. When increasing those settings used to make it respond better to pitch stick input for climb or dive.
But I tried it today with Cruise, using 8.0.. And its extremely sluggish, just as @jaroszmm said.

The reason I hadn't used it since 3.0. Is because I use an EdgeTX override function that switches out of Cruise to Acro, when either the Pitch or Roll sticks are moved more than a couple of percent either side of center. Then it returns to Cruise 1s after the sticks are released.. This makes changing altitude or heading so much more responsive.. Especially if we get dive bombed by an eagle.

@jaroszmm If your interested. This is the logic I use..
The XOR contains SB as my RTH switch. And SG is the switch position for Cruise.
The override is my position for Acro on Ch 5.

LC Cruz to Acro

SF Cruz to Acro

Remembering back. The reason I went down this path was because I had other flight controllers/software that would respond to an altitude or heading change in a 3D hold mode, just as fast as Acro does in INAV.. And considering I use Cruise more than any other mode for long range with INAV.. I found its response to stick input in Cruise less than ideal.

@breadoven
Copy link
Collaborator

@Jetrell Course Hold already uses manual position adjustment using the Roll stick albeit limited to the Angle bank angle limits I guess. It's only the Yaw stick adjustment that's more limited in response although it's much better after the recent change I made. Altitude adjustment is however not great. I guess it could be possible to have the option to manually adjust this, similar to the Roll stick adjustment in Course hold. But you could also just significantly increase nav_fw_auto_climb_rate and avoid excessive climb rates by careful use of the pitch stick.

@Jetrell
Copy link

Jetrell commented Nov 7, 2024

Course Hold already uses manual position adjustment using the Roll stick albeit limited to the Angle bank angle limits I guess

True. I was just trying to keep it on the climb/dive topic.. But yeah, roll response works well with a higher set angle limit.

I guess it could be possible to have the option to manually adjust this, similar to the Roll stick adjustment in Course hold.

That would help with pitch stick response..
A funny story that happened many years ago with INAV. A guy I was flying with crashed into a tree. And I asked him why he didn't pull up, and he said he was in Cruise and had full stick up applied. But the plane wouldn't pull up... And he didn't think to switch out of 3D Cruise at the time.
So I guess there are more than just a few users beside @jaroszmm that would think a cruise stick override would be useful.

But you could also just significantly increase nav_fw_auto_climb_rate and avoid excessive climb rates by careful use of the pitch stick.

With the changes you made to 8.0, does it now use auto instead of nav_fw_manual_climb_rate for manual stick climb rate override in altitude hold modes ?

@breadoven
Copy link
Collaborator

With the changes you made to 8.0, does it now use auto instead of nav_fw_manual_climb_rate for manual stick climb rate override in altitude hold modes ?

Sorry yes I meant nav_fw_manual_climb_rate not nav_fw_auto_climb_rate . Don't see why nav_fw_manual_climb_rate is set to a default of only 3m/s, would be better increased to the same as the Auto default of 5m/s. With only 3m/s it does appear that the pitch stick doesn't do much making obstacle avoidance tricky. Maybe it needs an emergency override at max pitch stick deflection which ramps up the climb rate the longer you hold it for.

@b14ckyy
Copy link
Collaborator

b14ckyy commented Nov 7, 2024

Its 2m/s default btw.
I think the climb rates are still more copter related where 2m/s is usually what someone would expect from a DJI-Like GPS drone.
The best option would be to change them in the Fixed Wing presets instead. We have a pitch angle limit already in case the throttle reaches max to not stall so it should be safe to raise the climb rate to 5m/s default on both. Most planes should be able to manage that.

But recently I also found out that we need a general overhaul of the default fixed wing navigation tune. Heading Controler P-Value is way too low imho. After ramping it up from 75 to 120, at least in HITL with 20kph winds, the path tracking could be reduced to 4 and it was about as precise and as little overshoot as in your latest code change @breadoven

Also the vspeed controller I think can be tuned sharper by default on wings. But that needs time and testing and probably not before 8.0.

@breadoven
Copy link
Collaborator

@b14ckyy
Copy link
Collaborator

b14ckyy commented Nov 7, 2024

Ah then it was changed in the past months because it was 2m/s in 7.1.2 if you check the branch tags.
As the Opener uses that version, we can assume his was set to 2m/s.
Still I think 5m/s are more reasonable for fixed wings.

@Jetrell
Copy link

Jetrell commented Nov 7, 2024

But recently I also found out that we need a general overhaul of the default fixed wing navigation tune. Heading Controler P-Value is way too low imho. After ramping it up from 75 to 120,

@b14ckyy That's one is interesting.. I run up to 110 on planes without a compass. While planes with a compass start having issues when the nav_fw_heading_p is higher than 75ish.

I have my planes set with a minimum of 6m/s climb rate. With a few set to 10.
The one I tested the other day with 8.0 in Cruise had nav_fw_manual_climb_rate = 700. And it still showed very poor climb and dive response to even full stick input.

Maybe it needs an emergency override at max pitch stick deflection which ramps up the climb rate the longer you hold it for.

Full stick deflection may be a bit harsh.. It wouldn't be responding, then it would all of a sudden shoot up or down.
I personally find a linear stick response provides a smoother feel over the requested action.

@b14ckyy
Copy link
Collaborator

b14ckyy commented Nov 7, 2024

What about the attitude control mode for multirotor? Where you can switch between atti and cruise.
Would make sense for planes. Atti would then switch to angle mode when stick is deflected while cruise works as it is now.

@P-I-Engineer
Copy link
Contributor

try lowering your min nav throttle to help with descending in cruise.
my dolphin wouldn't descend b/c the throttle wasn't low enough for it to lose alt.

image

@sensei-hacker
Copy link
Collaborator

sensei-hacker commented Dec 3, 2024

Maybe it needs an emergency override at max pitch stick deflection which ramps up the climb rate the longer you hold it for.

I would much rather see the max increased (with smooth, predictable scaling across the range) than have an exception where it does X -- except sometimes when it does Y.

This particular case would probably be fine - just as a general principle I think it's best to avoid getting in the habit of adding oddball exceptions. Those tend to lead to errors and bugs when someone doesn't think about them at a later point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants