Inav: Own Throttle value for failsafe RTH on Fixedwing

[FPVZaphod]

Current Behavior

Currently RTH uses cruise throttle to bring home the plane

Desired Behavior

An own setting for RTH throttle, or failsafe throttle

Who does this impact? Who is this for?

If the Cruise throttle for cruise mode is set for maximum efficiency, it might be too low to bring home the plane against high wind speed in higher altitudes. Without a magnetic compass, the GPS based home arrow might be even 180 degrees wrong, if the plane is flying slower than windspeed. If you're flying home with 50km/h, against a wind of 60km/h (results in a theoretical negative ground speed of 10km/h, but in reality it shows 10km/h but opposite direction), RTH will fail.
A higher Failsafe RTH Throttle can lower this risk. My plane has 1250 cruise throttle for high efficiency , but for a safe RTH it needs 1500.

[issue-label-bot[bot]]

Issue-Label Bot is automatically applying the label Feature request to this issue, with a confidence of 0.75. Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[avsaase]

Is this a theoretical scenario or has this happend to you? I ask because INAV is hard coded to increase the throttle in the gps enabled modes when the ground speed falls below 7m/s (=25.2km/h). I am not sure how it works exactly, but this should avoid the potential problem you described.

[FPVZaphod]

It happend already, but maybe my case is a bit special. I live in front of the Alps, where there is usually predictable and slow wind. There I keep my cruise throttle low for maximum endurance. But when I go to fly in the Alps between the mountains, there you find calm conditions close to the ground (<400m), but sometimes harsh wind when you're higher. Wind direction even changes there within a few 100m of flight. There is happend, that the home arrow got confused. More trottle fixed it.
It used to happen with my Caipi2, but not with the Strix Goblin. But I fly the Caipi more like a glider (50km/h) , and the Goblin like a Cruise Missile (100+ km/h) :-)

[MrD-RC]

Maybe the ability to set the minimum ground speed (in the UI) would be more useful. Afterall, if you can manually change the throttle in RTH, you could just fly home. The minimum ground speed would be more useful for RTH when you can't control the model, only autopilot. It would be handy to be able to set this in configurator for ease of use.

[avsaase]

Adding a cli command for the minimum ground speed is easy but I am not sure if that would be a complete solution. Say you are flying against the wind in angle or acro and use a high throttle value so you keep a positive ground speed in the correct direction. Then you engage RTH or a failsafe occurs and throttle goes down to cruise throttle. Ground speed falls, but before it becomes negative it first must go below 7 m/s, which should trigger a throttle increase.

Another scenario is that you fly away from you with a tail wind and a failsafe occurs which triggers RTH. The airplane makes a turn to fly back to you but never achieves a positive ground speed in the correct direction and keeps flying away from you, now backwards. How would you determine a minimum ground speed to avoid this problem?

I think the only true solution is for INAV to have a "flying backwards" detection, either by using a compass or some other test. One idea is to use the fact that the roll controls are inverted when flying backwards. This is probably also the exact problem that crashes your plane is this situation, so it should detect fast. Another idea is to use the wind estimation feature somehow, but I find that to be pretty unreliable on smaller planes. Once the detection is working the minimum ground speed setting can be changed to a "minimum ground speed in the direction the airplane is pointing".

Overall I think this is a pretty rare situation, which also makes it difficult to test a solution. As a temporary fix you can set up an adjustment for cruise throttle and change the value in flight based on the local conditions. Naturally you need to do this before a failsafe occurs or you're screwed.

[FPVZaphod]

The plane doesn't crash, because the true air speed it always positive as long as the motor is running. As soon as you have wind changes higher than your GPS ground speed, there is a risk.
A simple 2nd variable for RTH-Throttle would help a lot already!

[Mateyhv]

If during the autonomous backwards flying phase the plane does not crash due to aileron inversion control that should be called a miracle. A quick and dirty solution may be the RTH own cruise throttle but that wont prevent WP NAV and Cruise to get stuck into exactly the same problem.

[FPVZaphod]

Only the ground speed get’s negative, air speed of course remains always positive.
Yes, it also affects cruise mode, but at least in cruise you can switch to another mode, and add more throttle. In Failsafe-RTH you won’s have this option.

[b14ckyy]

I have an idea for a possible solution.
Background:
pre 2.1 INAV always used only movement vector for heading calculation, even if compass enabled. In 2.1 that changed due to the issue that some GPS calculated bad headings and enabling the compass, then used compass heading for navigation. The problem now is:
Without compass the plane flies straight lines to the target point like home and compensates for crosswind, but with very strong headwinds, this can mess with the heading if the wind is faster than the cruise airspeed.
With compass the headwind is no problem and the minimum ground speed can do it's job to make it back home but crosswinds will cause the plane to massively drift sideways and flies a spiral back home.

So my idea:
Primarily INAV should continue to use the GPS heading for flight direction all the time as it gives the most precise heading and it compensates for crosswinds to always fly the shortest path.
But INAV should compare GPS heading with compass heading if compass is enabled. If the deviation between both directions is off by more than 45°, this would mean that the plane either fights against very strong crosswind, that is close to the airspeed, or the plane is already flying backwards due to strong headwind. In this case INAV should switch to pure compass navigation to find the correct heading. So it will turn into the right direction and then the min ground speed can kick in and do it's job.

If the difference between GPS and Compass is back within the 45° error range, it can go back to GPS heading navigation after a few seconds as the min groundspeed threshold will keep the plane on track and it can fly back home in a straight line.

So Compass should only be used for navigation if the GPS cannot determine a correct heading due to wind.

[Mateyhv]

If you have a compass its not a problem, FC is always aware where the nose of the plane is. The problem is with GPS fix only. The ground track vector is where the FC believes the nose points. If you fly backwards due to wind the FC believes the nose is where the tail is, which inverts the aileron logic. So instead of compensating to stabilize on roll, its adding to the banking side and believe me the PID loop will make the plane roll faster than a screw driver.

The situation is saved because autonomous modes are driven in angle, thus accels take care of the plane's attitude.

[digitalentity]

If you fly backwards due to wind the FC believes the nose is where the tail is, which inverts the aileron logic. So instead of compensating to stabilize on roll, its adding to the banking side and believe me the PID loop will make the plane roll faster than a screw driver.

This is not correct. The airflow direction doesn't change, ailerons are driven by the gyroscope and have nothing to do with GPS vector. What would really happen, is that INAV will believe that it's flying away from home (which is correct) but will wrongly assume it has to do a 180 turn to start flying to home. So, the plain will turn it's nose away from home which not fix the problem, so the plain will be either wiggling or doing circles while being blown away from home further and further.

[b14ckyy]

If you fly backwards due to wind the FC believes the nose is where the tail is, which inverts the aileron logic. So instead of compensating to stabilize on roll, its adding to the banking side and believe me the PID loop will make the plane roll faster than a screw driver.

This is not correct. The airflow direction doesn't change, ailerons are driven by the gyroscope and have nothing to do with GPS vector. What would really happen, is that INAV will believe that it's flying away from home (which is correct) but will wrongly assume it has to do a 180 turn to start flying to home. So, the plain will turn it's nose away from home which not fix the problem, so the plain will be either wiggling or doing circles while being blown away from home further and further.

exactly. Happened to me already and not only once. Especially on a plane that flies slow but has a high turn rate, INAV won't b able to correctly determine the correct heading. When it turns into tailwind it will continue fly away and then it turns further to fly back but if it turns too fast, then it wil l still go backwards. And before the min ground speed ramps up the throttle and accellerates the blane against the wind, it has already turned around again and continues the circle.

So what do you think about the failsafe logic by switching to compass navigation if the GPS bearing and compass heading is off by too much degrees? Using it to stabilize the flight direction, ramping up the throttle by min ground speed and switching back to GPS bearing then?

[avsaase]

I personally wouldn't want to setup a compass if it is just used for this purpose and otherwise not used for anything.

Regardless of the logic, as long as the cruise throttle is insufficient to achieve a positive ground speed in the home direction the plane will never reach home, whether it points the nose straight home or does this circling away from home thing. Wouldn't it be possible to use the estimated wing speed and direction in some way?

[b14ckyy]

@avsaase the estimated windspeed only works if the plane flight direction and expected cruise speed is known and precise.
And no the min ground speed can safe the plane in this case if the plane does not turn too fast.

Example:
Keep in mind that min ground speed is 7m/s or 25km/h
Plane flies away from home with tailwind of 60kph and airspeed of 50kph and RTH is engaged. Movement vector is known and correct at this stage and ground speed very high (110kph).
Plane turns around and at 90° the crosswind will push the plane sideways with 60kph away from home and 50kph airspeed perpendicular to home course- So speed still around 80kph over ground.
Turn continues and is now at 45° from home. This is the point where the headwind still pushes the plane away but the airspeed is still 50kph and with that wind speed the movement direction will be around 90° off from the home direction but now go down to a ground speed under 25kph.
This is when min ground speed has to kick in BEFORE the plane goes backwards. It will throttle up to maintain the ground speed above 25kph. So the airspeed will raise now above the wind speed.
In this situation the plane continues the turn to fly directly to home and min ground speed will throttle up to keep the movement vector correct against the wind.

The only problem here is, if the plane turns too fast and has not enough time to accellerate to overcome the wind speed before the movement direction goes backwards, this can cause a navigation problem. Or of the windspeed is more than 25kph higher tan the airspeed.

---

Another option I might see is, to give more trust into the gyro data for navigation. if the GPS movement vector suddenly changes, this should not immediately cause a course change. Can we modify the Gyro/GPS Heading weight in the configurator?

[FPVZaphod]

I think a failsafe-throttle would be the easiest solution, but not for all. If you need every mAh to return home, it might drain the battery too much.
But this leads to another idea: What's about a throttle ramp-up to 80% or even 100% in the moment of RTH, but only for a short period (30secs to 1min) until the home direction is clear. Then going down with throttle again until reaching cruise throttle or minimum ground speed (the higher one of the two). This would ensure proper navigation in the most critical moment. Of course only if the plane can fly faster than wind speed, but if not, there is anyways no solution.

[b14ckyy]

this may have bad side effects. If I am high up like for cloud surfing or above mountains, I usually fly till my battery is nearly empty and glide back. Then I use Linear descent RTH so inav has to throttle down and glide back from high altitude to safe power. If it ramps up the throttle for no reason this will kill my battery, especially if it is a Li-Ion pack.

We should not consider any solution that will always consume unnecessary power when not needed. A course validation by compass would dou that without the need of extra power if not necessary. Especially as this is usually a very rare occurance it makes no sense to drain tons of power on every RTH.

[FPVZaphod]

Yeah, there is no free lunch... It would be only for Failsafe triggered RTH, not for a normal one.
And your cloud surfing example is the perfect scenario for such a problem. Low Throttle, and high altitude with possible stronger wind.

[b14ckyy]

But not using a fix for RTH also makes no sense. If the plane is 2000m up and you loose orientation you rely on the home heading error. With my method above the home arrow could be stabilized all the time, not only when RTH is active.

[FPVZaphod]

Yes, but when you "just" loose orientation, and you still have RC Link and Video, the fix is quite easy: Gain speed, as much as possible. This also fixes RTH. That's why I asked from the beginning for an own RTH Throttle.
None of my planes is prepared for using the compass, but I think it's very difficult to solve this without. At least home distance is reliable, so with working RC you can simply try in which direction it gets less.