iNavFlight / inav-configurator

GNU General Public License v3.0
581 stars 310 forks source link

Fixed Wing Defaults #1028

Closed moggiex closed 3 years ago

moggiex commented 4 years ago

Howdy,

When you first flash a board & connect, the user is presented with an option to select which type of aircraft they are using, air plane, multi rotor and some other options ( believe this is platform_type = AIRPLANE & applied_defaults = 3 in iNav).

If the option airplane is selected, is it possible to set the following options by default:

Features

Disable airmode so you see what the actual flight mode is, enable motors, pwm output and turn on auto launch by default.

I appreciate MOTOR_STOP enabled by default might cause a slight concern, how many comments have you seen of motors not working?

feature -AIRMODE
feature MOTOR_STOP
feature PWM_OUTPUT_ENABLE

Slightly controversi al as a new setting in 2.5, seems to work well even with a light model set nav_fw_control_smoothness = 2

RTH defaults.

Climb first is OFF as unlike a quad that would rise straight up vertically, a fixed wing model needs to climb steadily.

If a RTH condition has been triggered, it is a fair assumption the pilot wants the model to come home, thus turn and return. Climbing off into the distance to increase distance between the pilot and model even further is probably not the most suitable outcome.

nav_rth_altitude is set to 10 metres by default. Fine for a quad (probably), fixed wing, 50 metres is a more sensible value

nav_rth_allow_landing again, I could appreciate with a quad why this might work, however having a fixed wing model try to land at you by default when the RTH and then loiter is the standard is a bit nuts (ref Kopilot and Vector both return, then loiter).

set failsafe_procedure = RTH
set nav_rth_climb_first = OFF
set nav_rth_allow_landing = NEVER
set nav_rth_altitude = 5000
set failsafe_mission = OFF

This defaults to 100cm, which is nuts for a fixed wing model considering the typical wing span is 100cm or more! So 30 metres would be more sensible.

set nav_wp_radius = 3000

That's all the important ones I've come across, thoughts?

Matt

moggiex commented 4 years ago

Update:

Dominic Douglas set failsafe_mission = OFF This is to continue a mission/waypoint if RC link is lost. Can't see the logic of not having this off. If someone has their failsafe set to DROP you could start a mission and have the plane drop from the sky once RC link is lost. Most people would assume RC link isn't important for a waypoint.

Also autpo launch by default, I can see why that might not be desirable in all instances for PW (as per the thread here LINK IN INAV FW GROUP )

MrD-RC commented 4 years ago

I would leave airmode enabled. The bug where you saw the incorrect mode (AIR instead of ACRO) in the OSD has been fixed and will be released in iNav 2.6 https://github.com/iNavFlight/inav/pull/5711

Personally, I would also leave climb first on RTH on. While its true that you can never know what the environment you are flying in would be like. I believe that most of the time, you won’t be flying towards an obstacle. However, you could have trees or other obstacles either side if you when you failsafe (which would trigger the RTH). Perhaps, a smarter solution would be to have two settings and an altitude limit to distinguish them. That way you could have climb first if you are below 75m, or turn first if above.

moggiex commented 4 years ago

Hey Darren,

With climb first, the very last thing you need is the model going away from your further in a RTH condition.

Climb first makes sense for a quad, but definitely not a fixed wing model.

Why add more distance and a potential fly away (as there is a cut off to the amount it can climb for) when it's been triggered. Also refer to kopiolt and the vector here, those both turn first.

Matt

MrD-RC commented 4 years ago

I still think it depends on situation. If you’re at 399ft, then I completely agree that turn first makes the most sense. But, if you’re flying proximity between trees or through a tunnel of doom, the last thing you want is to turn; because there’s more chance that straight ahead is a clearer path. Why risk turning in to a hedge on failsafe? This is why I think being able to set both options depending on altitude would be a winner 🙂.

Believe me, I’m thinking of this from a 100% fixed wing point of view.

moggiex commented 4 years ago

If a model FS's in the valley where we fly, RTH doesn't work those models are using a vector and I refuse to set the setting to allow a lower than starting height RTH.

So it just glides into ground when (not if) that happens.

I was thinking about this earlier. Throw it to a vote Inthe FW group, keeping the bias to a minimum.

So lob up a poll with the two options below?

With iNav and Fixed wing models, if the model was to fail safe or you hit the RTH switch, which option do you want iNav to do by default?

1. Climb out in a straight line to your set RTH height and then come back

2. Turn around immediately and the climb on the way back to your RTH height.

Good idea and see what everyone comes back with over a week?

Matt

MrD-RC commented 4 years ago

That’s a fair call. At the end of the day, both options will still exist. I know with my setup, the most it will climb is about 90m, so flying away during that is no issue at all. And I’d rather not turn in to a tree if it happens low down.

At the end of the day, different pilots are going to have different preferences. That’s why having all the options in iNav is a good thing.

There was something else that it would be handy if it was set by default for planes. Ah yes. By default set gps_ublox_use_galileo = on. As most modules support Galileo these days. And if it can’t find the satellites, it doesn’t matter. There are only benefits.

andrewnewton commented 4 years ago

I changed from RTH "turn first" to "climb first" because I wanted to avoid a turn into climb and potential stall if you're flying slow and low.

hamishfagg commented 4 years ago

If you fly around a hill till you are out of LOS and failsafe, turning first will turn you into the hill and you will crash. Climbing first is the best option there too. I always have mine set to climb first.

breadoven commented 3 years ago

Why is there no RTH option to climb first whilst holding position, i.e. position hold but climbing ... it circles up ? I'm guessing this would already happen if nav_rth_home_altitude is set higher than the nav_rth_alt_mode home altitude. Looking at the code "climb first" on a FW simply sets a target WP 1km out on the current heading and climbs towards that WP at max climb rate limited by max pitch up angle. Was a circling climb found to be a problem before, unstable, stalling issues, and a linear climb used instead ?

MrD-RC commented 3 years ago

@breadoven The problem is that you could still potentially hit something and are wasting energy, the latter I believe is @moggiex issue with climb first. If you are flying away or loitering to gain altitude, you are using power and not getting closer to home.

I still think being able to choose different options based on an altitude would be the best all-round bet. Personally, I would set it to climb first if below 70m or turn first if above. If below the threshold, once you reach it, iNav would switch to the other RTH option. Best of both worlds in my eyes then. I could RTH at 40m, iNav would climb first up to 70m, then turn to home while climbing up to the RTH altitude. At the point of the turn, you should be at cruising speed, so the stall that @andrewnewton is concerned about should not happen.

breadoven commented 3 years ago

You've less chance of hitting something if you spiral climb up at the point of RTH because you should stay within the loiter radius during the climb. As to energy well that's only wasted if the climb isn't necessary but of it's a FS RTH it's impossible to know how high you might need to climb to clear any obstacles back to home so you can only set sensible RTH altitudes based on what you're doing and stick with those if a FS happens. If it's switched RTH then probably you have more control over what's happening so might want to override the preset RTH altitude and return at a lower altitude which is why I've made a couple of custom changes for RTH:

Altitude Override - Simply uses the AltHold switch to override the preset RTH altitude resetting it to the altitude when the AltHold switch is flipped. No use for FS obviously but very handy with switched RTH to avoid a climb to the RTH preset altitude when you know it isn't required.

Spiral Climb - does a loiter climb when Climb First is set. Uses nav_auto_climb_rate to control m/s rate rather than the pitch limited rate used by default. Works fine, you can tune the climb rate, loiter radius to avoid instability/stall issues if necessary. In fact this is what iNav does now if you set nav_rth_home_altitude and it has to climb/descend from the RTH altitude to nav_rth_home_altitude.

MrD-RC commented 3 years ago

@moggiex I have added a poll to the INAV Fixed Wing group. I figure it would have a larger response and more specific.

https://www.facebook.com/groups/INAVFixedWing/permalink/1458149804386813/?__cft__[0]=AZWTYCLkvNnGXPx5_eO7YIGTC5k2K8MpcrBoRt8WxEkQScZm9NZGhB7S6_9t72T6N8_IaFXdijtpgq4U2K7DEbx0VOYaPODsXeDqKAbaOPW_gj65geo1HYdN_7P3UjkRS6-HF2Zkt_cEHTvIGo9oKyBuCIlaokB-IgnugGPi5Q5-mxLvUio4fj9uefxqjfrvstLHhq2CmP-gDEa-6TBdmw-E&__tn__=%2CO%2CP-R

MrD-RC commented 3 years ago

You've less chance of hitting something if you spiral climb up at the point of RTH because you should stay within the loiter radius during the climb. As to energy well that's only wasted if the climb isn't necessary but of it's a FS RTH it's impossible to know how high you might need to climb to clear any obstacles back to home so you can only set sensible RTH altitudes based on what you're doing and stick with those if a FS happens. If it's switched RTH then probably you have more control over what's happening so might want to override the preset RTH altitude and return at a lower altitude which is why I've made a couple of custom changes for

Not really. If you're going to hit something turning first, you'll still hit it with loitering. As Matt pointed out, the minimum loiter radius you want is about 30metres. In fact, the loiter radius should be pretty similar to the turn radius of the model is you've tuned everything.

For the wasted energy, I'm not just talking about gaining height. There is a pretty good chance that with RTH we may need to gain height. The wasted energy is because we are not heading towards the home point while gaining the height. Whether we are loitering or just gaining height in a straight line. If we're not heading towards home, we will waste some energy. There's about a 3:5 chance the spiral climb will waste less energy than a linear climb. But, in that 2:5 chance, the linear will be heading towards home too. I think 72 degrees either side of the direct heading to home is a fair estimate.

I also agree that in different flying environments, the altitude where turning is safe will vary. But this is why you allow the pilots to define it. They should know the area they're flying in, so have a good idea of the altitude to set. It could also be added to the OSD menu for setting at the field.

I'm thinking of all this from the perspective of failsafe RTH, or an emergency, for example, losing video. After all, if you have control and can see where you're going, you don't really need to use RTH. You can just fly yourself. You can turn towards home, then RTH, being sure to avoid all obstacles.