FW Nav Course Hold control method change

[breadoven]

Changes fixed wing Nav Course Hold to control course direction using heading control only rather than flight toward a virtual waypoint position set some distance ahead on the course path. This seems the more correct way of controlling the course now #8529 has been implemented for Nav "heading" control.

HITL sim testing with 20 knot cross winds and gusting results in straight tracking on the set course. Still needs checking in flight though to confirm it works as well as the existing method.

[Jetrell]

Out of interest... What airframe did you use in the simulated test. Conventional tail or Flying wing?

In the early days before the virtual waypoint method was implemented for Course hold. A frontal crosswind acting on the airframe, would cause a Flying Wing to 'snake' far more erratically than it does with the current method.

It will be interesting to see how this turns out. Due to a frontal crosswind pushing the plane off course by nature. Then it having to bring itself back on course... Which will make it 'snake' regardless.

[breadoven]

Looking back though the code I got the impression the virtual waypoint method was used from the first version of FW Course Hold. Is this not the case ?

Needs flight testing for real with wind to know if this control method works. HITL is very useful but not fully representative of reality.

[Jetrell]

I remember reading somewhere, of development testing done by someone else, before the virtual WP method was adopted.
Here is a read of the original PR, if you haven't seen it already.
#1712

[b14ckyy]

@Jetrell regarding the used plane in the HITL is a good point. The NurkFPV Wing is actually a fake wing. In reality it is a Cub-Style RC plane with rudder and all, hence the yaw stability on this one. The model just hides all the elements and instead shows just decorative 3D models to fake the actual FPV wing.

Better use the VR Wing Noob that I published in the discussions section of the HITL Github. that's as close to reality I was able to get it without breaking physics.

[Jetrell]

Better use the VR Wing Noob that I published in the discussions section of the HITL Github. that's as close to reality I was able to get it without breaking physics.

I was hoping for the right conditions to test this in. But the wind has been remarkably calm of late. Which is good for flying, but not for this.
I think a good example of the virtual WP method is seen in - #8557
It appears the plane starts to get blown off course after each virtual WP. Then once it reaches half way between the two, It starts slowly tacking back into the wind, until it reaches the next VWP.

The other method, which is far less desirable. And I also used to experience it with the Eagle Tree Vector, in automated modes.
Was the plane being continually blown off its heading. Snaking back and fort to try to maintain that line. Maybe 10 times in a KM... It made me sick to fly with under those conditions.

Although, I don't think there is any other way, without a Mag and a good rudder, to hold heading, with a strong frontal crosswind. So its almost inevitable with a GPS and wing combo. That it will be one of these two methods used to hold heading... I prefer the current method.
But with the better wind estimator, it maybe less of an issue, and still work the same.

@breadoven Is there anything in the code to support my theory and observation in 8557, in a cross wind?

[b14ckyy]

@Jetrell I think the snaking should be prevented by #8529
as this will directly align the course over ground to the WP and compensate for wind by design as it did up to 5.1 already.
#8557 was caused by the new AHRS creating a virtual heading like if a compass is enabled and that error accumulated over time until it got corrected.

We also saw this in extreme form with cross winds after @breadoven updated the WP path tracking but after this change the path is dead center even in crosswinds at 50% of the airspeed.

[breadoven]

The reason for the flight path in #8557 appears to be down to the fact the wind estimator doesn't work well during straight flight, it needs manoeuvring in order to be reasonably accurate. This is just a limitation of wind estimation. So the wind based heading estimate from the new AHRS changes is just inaccurate in this case, i.e. the plane isn't heading in the direction INAV thinks it is so the Nav heading corrections are wrong. However, as you get closer to the virtual WP the heading error will start to increase taking you back in the right direction hence the curved flight path. This wasn't a problem before because, without a compass, heading was effectively just GPS ground course. If you used a compass it caused problems because INAV couldn't differentiate between changes in heading caused by wind effects or other reasons.

You don't have this problem if you're using ground course because wind and actual heading aren't so relevant. "Heading" corrections are only based on ground course error and in fact INAV doesn't care what "heading" is used it just makes corrections based on the error fed in which results in roll and yaw control outputs to correct that error. How good that correction is depends on how accurate the source of the error is, GPS derived ground course is simply more accurate than actual heading determined using potentially inaccurate wind estimates that appear to be slow to respond to actual changes in wind conditions.

[b14ckyy]

This is basically where this comes into play: #8533
Ground course is fantastic to fly straight in crosswind conditions but it sucks at navigation turns as the actual heading change does not represent the resulting ground course change.

So wind estimation could be used to calculate correct turns to get to the right course faster and more precisely but straight flying should rely on ground course only. It won't be perfect as we have no realtime wind but but good enough for proper turns and the rest is done by ground course corrections after the actual main turn,

[breadoven]

Managed to do some testing although only because the wind has dropped to not very much from the recent way too much. Seems to have been around 8 km/h with minimal gusting, direction Southerly. Tracks are for an AR Sonic wing 600:

Course error shown in the OSD was typically within 3 degrees max, often only 1 degree of error. So the tracks look pretty on course with no oscillation and nothing obvious in the OSD other than the usual flying wing wobbling about when knocked by a gust. This affected the heading by a few degrees but not the course error. However, needs more wind to see how that affects things.

[breadoven]

Also realised I'd missed something so make sure you use the latest version of this if testing.

[b14ckyy]

merged this into a test build I wanna test Autoland logic with. Course hold is very nice. Check the landings at 5:20 (Diagonal 20-25kph diagonal crosswind) and 8:04 (full 90° crosswind at same speeds/gusts).
The plane precisely adjusts its heading when getting slower and stays on track very well.
https://youtu.be/V1GYhMeuOR4
will refine a few things in the logic and make it ready for LIDAR and Flap use then I can test in the field as well

[breadoven]

I testing again a few days ago in flight with a conventional plane and this change worked well although there was even less wind than during the flying wing test so still not so useful in helping to understand how it will perform with rougher winder conditions.

[b14ckyy]

yeah currently it is not very windy here either. And if it is, I don't wanna fly at -5°C and bad gusts xD.

[Jetrell]

I had some windy conditions to test with today. The wind was 25-30km/h gusting.
The plane I used to test with was a Dolphin. Half way between a classic flying wing and conventional tail.

The firmware I used, was the last commit of this PR. Against yesterdays master.
The tests where all done in Cruise mode.
Multiple flight paths were flown, within 45° of the winds heading. Which was due south.
The lengths of each flight path, was between 1 - 2km.

Ultimately, both perform very close to each other. With this new approach, showing no bad signs.

The main difference was seen when the wind was pushing the plane from the rear quarter. I would often observed a course deviation, of up to 12° on the .GPX track and OSD course... This was corrected rather quickly, using the VWP method.. While it was a more gradual correction with this new method.

[breadoven]

I had some windy conditions to test with today. The wind was 25-30km/h gusting. The plane I used to test with was a Dolphin. Half way between a classic flying wing and conventional tail.

The firmware I used, was the last commit of this PR. Against yesterdays master. The tests where all done in Cruise mode. Multiple flight paths were flown, within 45° of the winds heading. Which was due south. The lengths of each flight path, was between 1 - 2km.

Ultimately, both perform very close to each other. With this new approach, showing no bad signs.

The main difference was seen when the wind was pushing the plane from the rear quarter. I would often observed a course deviation, of up to 12° on the .GPX track and OSD course... This was corrected rather quickly, using the VWP method.. While it was a more gradual correction with this new method.

Ah, that took a while to get the right conditions @Jetrell. Better than the UK though no doubt, too wet, windy or just plain freezing (briefly) to get anything done. Sounds like this method works OK, on a par with the existing method. It doesn't seem to result in any kind of instability which is the main thing.

Is it possible to post some GPX plots on here perhaps ?

[Jetrell]

@breadoven Yep, finally got the right conditions. Its been an unusual summer here.
The arrow is the wind direction.
The longest flight legs in these images, are just short of 2Km.

Current VWP method.

New GPS course method.

[breadoven]

There doesn't seem to be much difference between the 2 methods when you overlay the straight line course as shown in the attached GPX plots.

I don't think anyone will notice much difference between the methods in practical terms, not when it comes to deviations in the desired course at least. The thing you do notice with wind is the heading noticeably moves around which affects the camera view which might make you think it's going off course when if fact it isn't. Having ground course on the OSD is useful here. The other thing is the direction the camera is pointing is not where you will end up if there's a significant cross wind which might be confusing if you don't understand what's going on. In this case the corrections you'll need to make to keep heading where you intend will render any small variations in the course held by the plane irrelevant.

Both methods work it seems. This one is perhaps the more "navigationally" correct way but other than saving a bit of code doesn't offer any other advantage.

Current method

New method

[Jetrell]

@breadoven I agree with your assessment, concerning the way a crosswind effects the camera viewing angle verses the actual course.. I noticed this too in these tests, and I was predominately watching the COG OSD element throughout the flights.

From my earlier quote.

The main difference was seen when the wind was pushing the plane from the rear quarter. I would often observed a course deviation, of up to 12° on the .GPX track and OSD course... This was corrected rather quickly, using the VWP method.. While it was a more gradual correction with this new method.

Both these runs were on the down wind leg... But it could be coincidental, that the old method happened to hit a VWP at that exact position, or the wind backed off a little at that point, which corrected the track error faster..
Both these course changes were cross referenced on the DVR OSD course element.

New method

Current method

Both methods work it seems. This one is perhaps the more "navigationally" correct way but other than saving a bit of code doesn't offer any other advantage.

I have to agree.. I'm happy that it doesn't snake a course in strong winds... Its your call.

[b14ckyy]

Just my 2 cents on this: Trying to "fix" these marginal course errors is nitpicky.
at the end, yes the mode is supposed to hold a flight course over ground and not to follow a ground track or aim at a target by itself. If the wind suddenly picks up rapidly, error is expected until the new wind condition is compensated. At the end Cruise and Course hold are modes that are supposed to be flown manual and assist the pilot, not taking over the whole flight like RTH or WP do.
So, as long as there are no significant constant course changes and snaking flight paths, I am totally fine with that. At the end, aiming towards a specific target and expecting the plane to fly exactly there is impossible anyway in crosswinds unless we would have a pixel-OSD and can draw a flight path marker on the OSD with a perfectly calibrated camera angle to show the exact plane course over the FPV feed. occasional course corrections are therefore needed anyways.

From me this gets a green light.

[Jetrell]

@b14ckyy I don't really believe we're nitpicking.
I agree with @breadoven statement -

but other than saving a bit of code, it doesn't offer any other advantage.

It would be an easy choice to add this PR. If there was even a small performance advantage, over the VWP method. But there isn't.. Both have performed practically the same, with present tests. So, I'm neither for or against it.

The only concern would be, if there is a situation were the VWP method does perform better. And it hasn't yet been observed by us. But will be picked up after the release, by someone else, who fly's under specific conditions.
e.g. wind buffeting in mountainous terrain. Or a high HDOP with a low GPS fix, which may cause the direct heading control to be less accurate, than the VWP method.

[b14ckyy]

maybe we can push the PR in the master for the beta or RC phase and if anyone has issues, a rollback is easy.

[breadoven]

@DzikuVx Any objection to merging this ? Should give a couple of weeks for any complaints to surface.

[breadoven]

OK, I'll merge this. In reality there isn't much difference between this and the current method in terms of control. They both ultimately try to maintain a "heading/course" with the only difference being that the current method constantly updates the desired course to the virtual waypoint as it approaches it whereas this method sets a fixed desired course from the moment course hold is enabled. Not sure what the issue was originally with stability but maybe it's no longer an issue because of other flight control improvements made since.