Inav: POSHOLD not activated if ALTHOLD is already selected

[ghost]

MATEKF405-WING
Release 2.0.0 RC3
QUAD X

In 2.0.0, according to the release notes, selecting POSHOLD mode automatically activates ALTHOLD to provide a 3D hold.

By accident I have found that, if ALTHOLD is already activated (eg on a different switch) when POSHOLD is selected, POSHOLD is not activated (despite going blue in the configurator).

In the first log (real flight data), ALTHOLD is permanently enabled and despite numerous attempts, POSHOLD is never activated.

In the second log (bench test), ALTHOLD and POSHOLD are on the same switch so that ALTHOLD is turned off when the switch is set to POSHOLD and everything works correctly.

LOG 1.TXT
LOG 2.TXT

[KiwiDavid]

Hi,
I read that in the release notes but thought I may have misunderstood it. To my thinking this is a loss of a good feature - being able to fly vertically with no change in location. I've used this many times to take a short video by flying straight up, yawing slowly around and then coming straight down - often in wind and with limited location access - eg. building site or small clearing in the bush.
I can understand the idea of a 3D fix but keep it as 2 axis and 2 switches.
I guess you could still override the vertical movement of a 3D fix with throttle but the override function never feels quite as positive. Just my opinion.

Cheers,
David

[mrduncan626]

I thought I read something indicating that in 2.0.0, when selecting poshold that althold will automatically be activated.

[ghost]

Yes that is correct, selecting POSHOLD does automatically activate ALTHOLD and that works correctly PROVIDING ALTHOLD is not already activated.

What I found is that if ALTHOLD is already activated when POSHOLD is selected, it does not activate.

In my first log ALTHOLD the Quad is in "grand children" mode, where ALTHOLD is activated automatically when the Quad arms and stays activated for the entire flight. Despite repeatedly selecting POSHOLD, nothing happens, the FC stays in POSHOLD mode only.

In the second log, ALTHOLD is not permanently activated and selecting POSHOLD causes the FC controller to enter POSHOLD+ALTHOLD as expected.

Of course this may be intended behaviour, if not it is a bug.

[KiwiDavid]

In earlier builds you could not have a flight mode preselected when arming. I can't remember if it wouldn't arm or wouldn't assume the flight mode but several people specifically asked if they could have Alt Hold permanently enabled - partly to save switches (e.g. 6ch tx) and partly because it was easier for learning to fly quads.

Cheers,
David

[ghost]

David,
Yes that is correct, inav won't arm if a nav flight mode is preselected.

I circumvent this by programming the Tx to override the mode selection channel with the value for ANGLE only until the craft arms. A few msecs after arming, the override is removed and any permanent or switch selected nav modes are automatically activated.

This trick aside, the behaviour I was trying to highlight was if for any reason eg ALTHOLD and POSHOLD on seperate switches, ALTHOLD must be switched off before selecting POSHOLD, otherwise nothing happens.

[Dronitoni]

Hi guys,
if I have Althold activated on my quad, I need to give more throttle as usual to gain height.
Is this intended behavior?
Or is this just because of my settings in INAV?
Have Fun

[KiwiDavid]

Hi,
I think this is normal behaviour - you can override Alt Hold with throttle and Pos Hold with pitch and roll however they don't feel the same as when the craft is just in angle mode. Descending in Alt Hold mode always gives me grief - the craft seems to hesitate and further reduction in throttle then causes it to fall to the ground. Maybe there's some averaging going on and I'm changing things too fast.

Key thing is to focus on this AltHold/PosHold issue. When I first tried iNav 2.0.0 RC1 I thought that AltHold was not working and both my quads drifted. I normally test in a small backyard so I engage PosHold to fix the location but at this time I didn't realize that PosHold also fixed altitude so I then turned on AltHold to test this function and the quad just drifted up. This would seem to confirm flyfisher2's end result but arriving at it in a slightly different way. This is all making more sense now. I still would prefer the two independent functions and if I want 3D lock I push 2 switches.
With the new arrangement you still need 2 switches and you get AltHold and 3D PosHold. With the old system the same 2 switches gave you AltHold, LocationHold and with both engaged you have 3D PosHold.

Cheers,
David

[ghost]

Hi David,
Just to clarify, are you saying that when you selected POSHOLD, both POSHOLD and ALTHOLD were activated as per the new spec but when you then selected ALTHOLD on another switch, it appears that ALTHOLD became deactivated because the Quad started drifting up?

[KiwiDavid]

Yes - that's initially what it appeared like on both my 250 and 450 quad.
When testing in the limited area at home I have to engage PosHold to avoid the wind drifting me in to trees and fences and then I engage AltHold to check for stability and oscillations. At this stage I didn't realize that the new firmware linked PosHold and AltHold and that's when I thought the AltHold function wasn't working because both craft drifted up. I had also noticed that when engaging the PosHold function the craft revved up and jumped up a little - it should have indicated to me that there was an AltHold going on but it didn't occur to me at the time. Never before had I seen the AltHold not work or the PosHold give a small jump. (should have read the release notes carefully)
I need to revisit this to check but it may be that having both functions on disables the AltHold. (i.e. not the order in which they are switched on).

Cheers,
David

[ghost]

Interesting.
In summary then it appears that there are 2 issues:
If ALTHOLD is already activated e.g. by a separate switch, when selected POSHOLD does not activate - my experience.
If POSHOLD (and ALTHOLD by default) is already activated, selecting ALTHOLD on another switch deactivates ALTHOLD - your experience.

[KiwiDavid]

That's what it seems like to me. My original post on this was #20544 where I was confused that the AltHold switch appeared not to work (PosHold would have been engaged). I knew the baro worked because the missions seemed fine and the change of mode was detected in the blackbox log.
Weather permitting I will try to get some time on this tomorrow.

Cheers,
David

[ghost]

In my case, took off into a fairly stiff head wind and almost ended up with the quad in my lap, it was pretty obvious that POSHOLD was not working.

[KiwiDavid]

I can't say I had that issue - mine was holding the location but I'm still unsure the altitude hold is working as expected however I haven't tried AltHold alone, only with PosHold also engaged.

[giacomo892]

@flyfisher2 Closed means it is no more an issue?

[ghost]

No, I still cannot get POSHOLD to work but since no one else has reported a problem with POSHOLD in release 2 and the devs don't seem interested in this issue, did not see any reason to keep it alive.

FYI today with winds less than gale force for the first time in weeks, no matter what combination of ALTHOLD/POSHOLD switches I tried, POSHOLD never worked. Switching from ANGLE+ALHOLD, where the craft drifted around in the breeze as you would expect, to POSHOLD, caused it fly backwards at increasing speed. BB log shows that POSHOLD was activated but for some reason didn't work. (I originally thought that this behaviour was due to POSHOLD not being activated and a strong head wind blowing the craft backwards.)

I have used inav almost since the first release and this is the first time I have had a problem with POSHOLD, so goodness knows what is going on.

[giacomo892]

I'm interested in checking what's the issue is.
Please post logs and configurations of FC and Radio

[teckel12]

I've used POSHOLD and ALTHOLD extensively without issue in 2.0.

I have a single 3-way switch with the middle position being ALTHOLD and the 3rd position being POSHOLD.

Previous to 2.0 the 3rd position was both ALTHOLD and POSHOLD, but now it's POSHOLD only as it now enables ALTHOLD automatically (which I think is a good idea).

[crashfrequently]

Thanks guys for your interest.

@teckel12
That's exactly my switch arrangements pre and post 2.
I was intially fooled by the weather conditions into thinking that having both ALTHOLD + POSHOLD on position 3 was preventing POSHOLD from activating in 2.0 but removing ALTHOLD has had no affect, so something else is responsible.

I bought the MATEK WING for future use in a FW but thought I would check it out on my trusty old QUAD first. I think new FC plus new software may a bad combination. I'm now going to start fresh with 1.9 and see what happens if and when the horizontal rain around here stops.

@giacomo892
LOG #208 was a basic hover test in ANGLE+HEADINGHOLD+ALTHOLD.
Very smooth and controllable until 00:52 when I briefly switched ALTHOLD off and POSHOLD on. Quad immediately pitched up slightly and flew backwards (straight line, no toilet bowling).

Log #210 HEADING HOLD+POSHOLD, QUAD kept trying to fly backwards.

DUMP.zip
LOG00208.TXT
LOG00211.TXT

[teckel12]

@crashfrequently I wonder if your magnatometer alignment is correct.

[ghost]

oops, looks like this PC was logged in to my son's account when I submitted the last comment.
hence the user name change.

Yes it reads correctly when rotated and tilted etc
I replaced an F722 with the F405 WING in this frame, other than re calibrating the new FC, nothing else was changed.

[giacomo892]

So the issues is not "POSHOLD not activated if ALTHOLD is already selected" since the mode is been activated.
I suggest to check interference or misconfiguration. Where is the mag placed?

[ghost]

Yes the issues is not "POSHOLD not activated if ALTHOLD is already selected"
It's also nothing to do with 2.0 because I have just reverted to 1.9 and POSHOLD does not work with that release either.
The GPS pod is mounted on a pole well above the main deck and I've never had any mag related problems in the three years I've been flying it. The FC is mounted in a Faraday cage and currently no FPV gear is installed, so I don't think RF interference is the problem.
As I mentioned in my previous post, I replaced a F722 with the WING to test it before using it on a FW, nothing else was changed so it is beginning to look like a weird FC problem.
Things to try next, reinstall the F722, try my spare F405 WING, change GPS unit, tear hair out.
I'll let you know what happens.

[teckel12]

@flyfisher2 Really sounds like a magnatometer alignment problem to me. Can you point it in each 90 degree direction and it locks directly to that and doesn't drift?

[ghost]

The mag still checks out OK, accurate 90 degree readings, no drift, no appreciable change when tilted.
Also when the craft gets blown off position by the wind it maintains a rock solid heading, just does not make any attempt to return to its home position. In other words it appears to be flying in ANGLE+HEADINGHOLD mode only.
However just to be sure, next move will be to try another GPS unit.

[ghost]

Re-installed the previous FC (F722 running 2.0) and POSHOLD is rock solid,
Must be an issue with the MATEK WING configuration.