Feature Request: "Heading Hold" for Flying Wings

[moggiex]

Howdy,

Heading hold only uses yaw control (rudder) so it won't work on a flying wing which has no rudder.

I wondered why heading hold didn't work on a flying wing, the answer is here https://github.com/iNavFlight/inav/wiki/Modes#heading-hold :)

How complicated would this be to add heading hold for flying wings?

Coming from using vectors for the past ~6 months, sticking a model into 2DH (stabilized and heading hold) is a useful feature.

For example you're on your way back from a flight and you want to grab a sandwich, from the flight bag next to you, swap the FPV goggles battery over or just enjoy the flight with the thumbs off the sticks, the model flies in the direction you pointed it in, at the same height, until stick input is made to change direction or height or another mode is selected.

Matt

[martinbudden]

@digitalentity , I agree. This would be a useful improvement.

[moggiex]

Also for clarification, the model maintains its height and direction, unless stick input is made.

If a new direction and/or height is made using stick input, on the sticks centering, the model maintains that new direction.

Matt

[digitalentity]

Impossible to do properly without airspeed sensor, but I can probably hack something together.

This can be done via a new setting fw_heading_hold_mode with two possible settings YAW and BANK.

YAW would keep current logic.
BANK would calculate required banking angle and execute. Will probably require activating TURN_ASSIST mode to function properly.

Thoughts?

[moggiex]

Howdy,

So YAW would be for models with a rudder and BANK would be for models with elevons?

Daft question, could this not be automatically determined by the model choice on the configuration tab and be set appropriately? (sorry I've not looked at any of the iNav source code to make an informed note on this, so keeping it at a basic level)

Also the requirement of a secondary function, say TURN_ASSIST, would require the user to know about such a requirement, as such for complete novices, would it be better as a separate flight mode, where any sub modes, such as TURN_ASSIST or one of the stabilized modes are implicitly implied to that mode.

Oh I hope that makes sense!

Basically, a separate mode, any required modes to make it work and bundled in so the models movements in the air are what a user would expect. Just like with RTL, the throttle is managed, height and also stabilization too.

Matt

PS. I don't use a pitot tube with the vectors and it holds height/speed/direction OK in 2DH mode for both flying wings and normal fixed wing models, so can't be completely impossible :D

[digitalentity]

The new setting would define a method of control for heading hold - either with rudder (YAW) or with ailerons (BANK).

Now let me explain behavior in both modes with and without TURN_ASSIST:

YAW w/o TURN_ASSIST:
Only rudder will be deflected. Plane will maintain attitude (roll and pitch). In ANGLE mode and no stick input this will result in flat turn.

YAW with TURN_ASSIST:
Same as above.

BANK w/o TURN_ASSIST:
FC will bank in the direction of the required heading correction. If plane has rudder it will counteract the turn resulting in banked flying in a straight line.

BANK with TURN_ASSIST:
FC will bank in the direction of the required heading correction. TURN_ASSIST will calculated required rudder and elevator deflections to maintain banked turn and keep the nose on horizon.

[digitalentity]

Therefore BANK with TURN_ASSIST is suitable for all types of planes, but might be undesired if one want to fly flat.

[moggiex]

So the daft question to ask here is that with "BANK with TURN_ASSIST", combined with say NAV ALTHOLD would created the desired effect on a flying wing?

Matt

[digitalentity]

@moggiex yes. HEADING_HOLD/BANK + TURN_ASSIST + ALTHOLD will maintain heading and altitude. Won't help with sideslip due to crosswind though.

[moggiex]

Outstanding!

I can't help but wonder if this couldn't be rolled up into a new mode called "NAV HEADING HOLD" that sports all 3 options combined.

The code would know whether to use YAW or BANK from the original airframe selection, MAG if enabled and also it would be easier to see on the OSD, plus easier for users to setup (no required "special" combination of modes on the modes tab).

Matt

[digitalentity]

Hm... This is not as simple to implement as I thought it would be. Basic flight modes are deeply integrated with navigation system and adding HEADING_HOLD/BANK may (and actually will) break navigation capabilities. I need to think about how this can be nicely resolved.

Most likely we'll end up with heavy rework of airplane navigation control once more 😄

[moggiex]

Arh, not so simple then.

On the bright side, this was the only thing I could find missing in V1.7.

Also a little bit of positive feedback for you @digitalentity I've only hit RTL in anger twice in +6 months, once when I had temporary video blackout 6 months ago using a vector and once yesterday with iNav and it got the model home.

Ironically no more than 250M away as well! I got the model in behind some woods I normally fly through, a combination of heavy cross winds, low air speed and a thermal shook that model almost over twice. The video was going, the model was going to get ditched, it was horrific. I hit RTL as a last ditch attempt, zip, it was home. Most impressed 👍

Matt

[digitalentity]

@moggiex thanks for the feedback. I keep saying that RTL (and more importantly Failsafe) is not a magic button that will 100% save your craft - but there are mishaps where it's handling things better than a humal pilot.

On the topic: the more I think about reworking things here - the more I'm getting to believe that it's actually the right thing to do.

For multicopters it's quite simple - we let PID code handle roll/pitch/heading and navigation provides guidance. For airplanes it's all mixed up. Yaw/heading may be controlled by PID code and by navigation code. It isn't pretty, but it works. Now with increasing demand for heading hold on flying wings - let's finally make it pretty 😄

[digitalentity]

Opened an issue to track the new task - #1714

[digitalentity]

Btw, does any other flight controller limit climb and dive angles separately?

[digitalentity]

On the other hand - it may be better to do things differently. So, options for fixed wing:

A. Remove heading control from navigation, unify heading control under stabilization control

Pros:

• Allow HEADING_HOLD mode to be able to handle flying wings.
• Better unification of the heading control code; All heading control will be done in one place

Cons:

• Massive and bug-prone changes to codebase
• Will require splitting separate STEERING flight mode for heading hold when doing runway takeoff

B. Implement additional heading hold under Navigation system

Pros:

• Simpler from user perspective. Most pilots will want AltHold + Heading hold - which could be unified under a new navigation flight mode. Will handle flying wings as Navigation already does
• Simpler implementation-wise; Most of the code is already there and verified to function properly
• HEADING HOLD will still be allowed to control rudder-only for runway takeoffs

Cons:

• Likely won't fit in memory on F1 targets (CC3D, NAZE)
• Less flexible solution (i.e. no heading hold without altitude hold on rudder-less planes)

@marbalon @moggiex @oleost @DzikuVx and other fixed-wing flyers, let's discuss.

[moggiex]

Btw, does any other flight controller limit climb and dive angles separately?

The FY not to my knowledge, the Eagle Tree Vector, not seen a setting for that. Although not gone looking specifically for that option as it works exceptionally well out of the box.

Just checked and it has values for "desired climb rate" and "desired descend rate", along with minimum ground speed.

You can download the app here http://www.eagletreesystems.com/index.php?route=information/information&information_id=12, press ESC to get into it with out a controller enabled and then see the "Safety/Nav setup tab"

Mission Planner (Arduplane) & QGroundControl (PX4) "probably". Both of these have "one billion" settings (that is the correct number lol!) and none of them solve the issue of the OSD being the weakest link of the chain.

Hope that helps, Matt

[Redshifft]

DE, what am I missing here :) say we just add a Cruise mode, current altitude locked and an imaginary waypoint set off the nose 1K, 2K even 10k . A wing can navigate to home so it can navigate to a distant waypoint, yes ?

[moggiex]

@Redshifft thats just downright dirty and I like it :)

When the model gets anywhere near that imaginary waypoint, it'll need resetting to a new one as it's not unheard of for a pilot to do 10K in a straight line.

Matt

[digitalentity]

@Redshifft I like it. And if the pilot moves the roll or yaw stick - recalculate as well.

[Redshifft]

@digitalentity I just hate to see you clever ba$tards looking for complicated solutions to simple problems :D

[Dronek]

I'd like to include some ideas and a previous discussion that has been going on here.

Let's get back to the initial request:

For example you're on your way back from a flight and you want to grab a sandwich, from the flight bag next to you, swap the FPV goggles battery over or just enjoy the flight with the thumbs off the sticks, the model flies in the direction you pointed it in, at the same height, until stick input is made to change direction or height or another mode is selected.

Actually, when crosswind is involved and you enable heading hold, the model won't fly in the direction that you point it to. With magnetic heading hold, the model will dirft sideways and with gps heading hold it will drift as well, because it was drifting at the time of switching heading hold on. As far as I understood, inav mixes magnetic heading (if not disabled) and gps heading into one general heading but the mentioned drift should nevertheless persist.

DE, what am I missing here :) say we just add a Cruise mode, current altitude locked and an imaginary waypoint set off the nose 1K, 2K even 10k . A wing can navigate to home so it can navigate to a distant waypoint, yes ?

But how do you determine where the aircraft's nose is pointing when crosswind is involved? This could only be done by having magnetic heading available. It can not be based on GPS heading. Once a distant waypoint is set, it would be nice to not only have the model fly there but in addition on a possibly straight path, regardless of wind direction. For this purpose it might be more practical to interpolate the straight path to a distant waypoint by multiple points and make the navigation based on the deviation (error) from this actual straight path.

I like the fact that many pilots share their ideas on improving inav with respect to fixed wing navigation and I'll keep stressing that a working compass is not a useless sensor for GPS equiped fixed wings :)

[Schalonsus]

lets do it like @Redshifft suggested

[raul-ortega]

DE, what am I missing here :) say we just add a Cruise mode, current altitude locked and an imaginary waypoint set off the nose 1K, 2K even 10k . A wing can navigate to home so it can navigate to a distant waypoint, yes ?

Some time ago, in a issue that was related with this one, I suggested this method as a solution for the heading hold, but nobody took it into acount...

[Schalonsus]

#982 #1416

[Redshifft]

@raul-ortega well the prize for coming up with a great idea is only a big kiss from Konstantin - i'm quite happy you get the award :D

[sppnk]

The real problem is to define where the nose is pointing. It seems obvious, as you are seeing the desired destination with your googles, but as @Dronek stated, drift is involved, and it is not so obvious.

In aircrafts with no MAG I guess this is not possible,

[Schalonsus]

Even the oldest Cyclops Storm OSD has a kind of Heading Hold for wings

[digitalentity]

This is the longest and appears to be the most active thread, so I'm closing #982 #1416

[digitalentity]

Let's call the new mode NAV CRUISE and do it as suggested by @Redshifft. It will work regardless of having a compass or not, however in case of compass it will be more accurate.

[moggiex]

So looks possible then and not too much of a headache after all then chaps?

[digitalentity]

I'm not so sure about headache - debugging will certainly be a pain the the back, but implementation-wise it shouldn't be too complicated.

[sppnk]

Great, but, how will be the nose heading calculated just with a gps?

[digitalentity]

With GPS we assume that course is where we want to go. Will lead to some error due to sidewind, but that's true for all applications where we require heading - we'll have to cope with it.

[Redshifft]

@digitalentity if possible just make that mode a "Lazy" update so it does not fight drift and turbulence continually.....am I making this harder :)

[sppnk]

Finally I guess it is a good solution. If we engage NAV_CRUISE but the airplane is drifting, we only have to make some correction with YAW stick and then the trajectory should be what we need. Not perfect, but enought for CC3D pilots :-)

[marbalon]

+1 for the @Redshifft suggestion. Just set the WP based on current ground course. It is not so complicated to implement and enough to help pilot during long FPV flights.

[Rups63]

@Redshifft I like it too. I believe the distant waypoint implementation for heading hold is what APM uses for Cruise Mode - and that works beautifully well on a Stryker delta wing I have an APM Mini 3.1 installed in.

[Redshifft]

@Rups63 I was not consciously aware of anyone else doing this but as I did not think for long for the idea I'm sure others came to similar conclusions :)
The important thing is we get it to work well.

[Schalonsus]

Any news regarding this topic?

[digitalentity]

Will follow the 1.9. Proof of concept implementation is ready, but testing it will hold the 1.9

[Schalonsus]

Will this feature ever come alive? Whats so important that it is delayed every single version?

[shellixyz]

Probably not since iNav is at EOL 😄

But seriously it will eventually. It is just that developers time and number are limited. But all contributions are welcome ;)

Take a look at the current PRs to have an idea of what is going on:

• This is pretty important and long overdue: Mixer refactoring - make FC unaware of anything besides mixer rules #2978
• This is important and a nice improvement of TPA: TPA improvements - smoothing and delayed response of throttle-based TPA #2966
• This is also important: Initial cut on full quaternion IMU conversion #2894
• This also: GPS acceleration compensation for IMU #1481

All the PRs ready for the next version: https://github.com/iNavFlight/inav/milestone/17?closed=1

[stale]

This issue / pull request has been automatically marked as stale because it has not had any activity in 60 days. The resources of the INAV team are limited, and so we are asking for your help.
This issue / pull request will be closed if no further activity occurs within two weeks.

[shellixyz]

This issue can be closed when #3311 will be merged

[digitalentity]

Closed via #3311