How to get RTL and Cruise to fly without turning the motor?

I have a motor glider, and I’ve noticed that if I’m at 100 meters and RTL is at 50 meters, RTL will fly back with minimal power, but it’ll still turn the folding prop, wasting power and actually maybe even slowing down the plane compared to having the prop folded and gliding down to target altitude
I already have
THR_MAX,60
THR_MIN,0

I’m a bit worried about setting TRIM_THROTTLE to 0 or is it some TECS setting?

Similarly I’d love for a way to have CRUISE maintain a safe airspeed and heading but only turn on the prop if I have throttle at something more than 0. Otherwise, it would just lose just enough altitude (or not if I get thermals) to maintain ARSPD_FBW_MIN until it gets too low and hits FENCE_MINALT if enabled.

Regarding your last request CRUISE will always try to hold ALT and use power - that’s what its for. However, if your plane is trimmed well and you set it on a heading and into FBWA mode and 0 throttle it should glide extremely well and level. You could simply throttle up if needs be. The fence will also still trigger if you get too low and cross FENCE_MINALT.

Thanks, Grant.

Thanks. I indeed use FBWA for now.

The one that worries me more is RTL. If I have altitude to spare, but the battery is low, I don’t really want RTL to turn on the motor and waste battery to fly back when gliding would be enough (I’m above RTL return altitude).
Any idea on that one?

Thanks

I thought about that some times ago. To me, this issue reduces the range that RTL is actually able to achieve.

I think there is no feature to say “this is a glider, so set throttle to 0 if we are far above the RTL altitutde”. I personally think it would deserve an additional parameter + a simple code modification. I don’t know how hard it would be to push some modifications to the code…

So instead, I use another strategy: I set ALT_HOLD_RTL to -1, so the APM will try to maintain the current altitude (using the motor). Then I use a conservative ESC setting to stop the motor on low battery. Once the battery runs too low, the ESC will simply stop spinning the motor, and the plane will glide the remaining part of the flight despite the APM requests some throttle.

But here too, the ALT_HOLD_RTL is not perfect: I would like something like “Maintain current altitude if it’s above a certain height, but climb to that predefined height if the current altitude is below”. This is just in case I fly low (say 20 m) when I lose link, I’d like my plane to climb back at 100 m during the RTL process so it doesn’t hit any object in the path.

You make some interesting points, but forgetting new settings, there is no reason for RTL to even spin the motor as long as it’s above its target altitude for some airframes.
Isn’t there a setting where I can give it minimal throttle for cruise and set that to 0?
This would work on RTL where it would know that it can shut off the motor if it doesn’t need to gain altitude, and CRUISE could have a (new) setting where it would accept climbs due to thermals without trying to get back down and not spin the motor until it starts getting below the initial altitude it had when CRUISE was enabled (although yes, FBWA kind of works, but not fully if you really want to keep a heading and would like the altitude protection in case you dip below your starting altitude)

I observed the same behaviour on my aircraft. I haven’t got a folding prop but I turned the ESC’s brake function ON, because a spinning prop has more drag than a static prop. To my surprise when it needed to descent a long way in RTL it was still using the prop, increasing drag and wasting electric energy. The descent vertical speed (5 m/s) was maintained and the airspeed was actually above target airspeed. So why use the engine? THR_MIN = 0 and in FBWA the prop does not spin when I close the trottle.

Could it be a TECS command? Maybe because the speedweight function averages a lot of things, it gets a throttle input from somewhere which it partially executes? I’m only guessing here. Next time I’m going to try the speedweight settings to their extremes, to cancel out any averaging between using the pitch or using the engine, to find out.

First I’ll try 2.0: My hope is, because it makes the pitch loop focus fully on airspeed, it makes the engine focus fully on ‘keeping the descent path’ (5 m/s). Because the descent path is too steep to make when keeping target airspeed constant, it has to close the engine fully. The descent vertical speed it achieves wil automatically be best glide (if the target airspeed is correct according the aircrafts flight envelope) This setting should work nicely in climb as well and is similar to a “Level Change” function on a full scale aircrafts autopilot.

After that I’ll try the opposite, speedweight 0: It should then focus pitch on keeping the altitude or descent path in this case. This is too steep in my testcase so the airspeed becomes higher than target airspeed. The engine should focus fully on airspeed now so should close the throttle. This setting is similar to a “Vertical Speed” setting on a full scale aircraft autopilot.

I hope the developers will add a different speedweight function for climbing/descending and keeping the aircraft on altitude when flying level. I don’t like the idea to climb and descent using an intermediate of “Level Change” and “Vertical Speed” functions. And when I want the autopilot to go into an “Alt Hold” function, use this same intermediate setting which might cause bad altitude keeping. I think the climb/descent speedweight should be more towards 2.0, and the altitude hold speedweight should be towards 0.0.

I have opened a topic about this extra speedweight funcion here: viewtopic.php?f=113&t=13900&p=38169#p38169

I’ve filed this RFE/Bug here for now: github.com/diydrones/ardupilot/issues/3062

Was glancing briefly at this today, but without a log to review it’s hard for me to make any progress on it. (My plane usually needs some throttle to maintain the airspeed/altitude balance, although I do see it shut the motor off if possible due to thermals (and at or above cruise speed)).

Does anyone have a log demonstrating the problem they could share?

I opened a bug here with details https://github.com/ArduPilot/ardupilot/issues/3812

Hope this helps.