Inav: AUTOLAUNCH enhancement discussion

[giacomo892]

Hello everyone, as you may already know I'm interested in improving autolaunch mode.

I've came up with some ideas I want to share and discuss with you all.

1. Show launch phases on OSD (helps with planes without a buzzer for instance)
2. Add a "stage2" launch phase: This phase is intended to reduce the stress on batteries (which may be even cold) expecially LiOn batteries and also to reduce the average energy use during the launch phase. My idea is to start reducing throttle and the pitch angle(to prevent a stall) after some seconds of climb (or at a specified climb rate).
3. Ability to configure some autolaunch parameter via the configurator

Do you have more suggestions? Ideas? Improvements?

[Pairan]

so instead of climbing constant 20° for lets say 10sec you want to lower the angle to 15 and reduce throttle after maybe 5sec to reduce stress and energy consumption?

how will autolaunch figure it has completed? As the angle changes, only the time is left.
By now i think its the time and the angle it has to maintain, right?

Things maybe to consider here:
1) you will need to have an eye on the minimum speed after decreasing throttle, as you otherwise could stall (too)!
2) it seems harder for normal persons to configure it compared to the present setup as the necessary parameters will increase

I understand that you want to reduce the stress on the batteries but I dont think it helps autolaunch so much. But thats only me- other opinions?

[giacomo892]

@Pairan I've based my idea on the consideration that the launch throttle is much greater than the needed one some moments after the plane assumes positive rate.
I'd say, put after 2-3s, of hard climb we may switch to a more controlled gentle climb like reducing the pitch angle and the throttle much the navigation subsystem does when it manages automatically throttle and pitch during automated modes. If it is done right I suppose we could only benefit from it. Regarding the configuration it could even done with a single parameter in percentage like nav_fw_launch_stage2_thr=100 means maintain the same throttle and climb angle. Setting lower than 100% will reduce throttle and climb angle with the same percentage. Indeed we need to fine sane values like [90-100] for a flying wing should be ok. eg with nav_fw_launch_stage2_thr=90 if you you a launch throttle of 1700 it will go down to 1630 and the climb angle from like 28 degrees to 25 degrees. nav_fw_pitch2thr can be used too as reference.

[shellixyz]

My opinion:

1. Sounds good. I like the idea.
2. 2 stage launch:

• Would add complexity to the launch settings and code but it could be beneficial to preserve the battery depending on how you use it.
• Not sure it would be very useful at least in my case. I'm often leaving launch mode between 2 and 4 seconds after launch. You could launch with the mode set to ALTHOLD and the launch timeout to a small value (or not). After leaving launch mode you would just have to pull on the pitch stick to set yourself the climb rate as you like.
• If a stage 2 is implemented I think using the ALTHOLD controller for the second stage would be the best. Just add a nav_launch_climb_speed and let the nav_fw_cruise_thr and nav_fw_pitch2thr settings control the throttle.

1. Launch configuration through the GUI: of course that would be nice.

[OlivierC-FR]

Something that would improve autolaunch : The FC should start to climb only AFTER the motor is spinning at the set throttle. Before that it should be at neutral pitch.
Right now it's pulling as soon as you engage the autolaunch, on some planes (my miniDrak) that are tricky to launch because the stall speed is quite high, it's really getting in the way, it's actively attempting to stall the plane before it has built enough speed.

It could even benefit an extra delay before pulling, same way the motor start is delayed after the launch detection.
Launch detected >> nav_fw_launch_motor_delay >> nav_fw_launch_spinup_time >> "nav_fw_launch_fly_horizontal_to_build_enough_speed_delay" >> Begin to climb only now

[digitalentity]

@OlivierC-FR good point. We might have a parameter for delay before starting to pull up similar to nav_fw_launch_motor_delay

[giacomo892]

@OlivierC-FR @digitalentity Good point. I suggest to keep some degrees of elevator pull before giving full pull up just to avoid the plane hitting the ground if the launch was not good enough and also to give a bit more reflex on launch to wings 💃 An hardcoded 1/4 of full angle could be nice. (it has the downside advantage to let the pilot know that surfaces are moving correctly before the launch which is nice!)

[Redshifft]

The Boys are right you don't put control input until the thing is flying with control authority. Any early control input will be sure to put the thing in the ground.
An Auto launch has about 0% chance of saving the plane from a bad launch compared to a good pilot as it can only work with a pre programmed routine.
Maybe an option for switch triggered auto launch would be good as the pilot could launch at zero/low power and then decide if the launch was ok before switching to auto?

[devish1]

I will add to the difficulty: glider launches. I've started to use INAV with a slope soarer and trying to get a working DLG toss routine. Main issues are: INAV changing PID values based on throttle (don't have one) but have almost cobbled together a routine for a stabilized DLG launch.

Took some time to figure out why my servos did not work properly on launch setup (TPA and boost issues linked to throttle). Eventually, will work around it... but was not obvious. Plane works great with "boosted" P / zero throttle - not so much with attenuated throttle significantly reducing the P values.

Also - does the reduction in "I" occur at zero throttle? Not well documented.

It did not help that I added 100% TPA to a pot on my controller to adjust PIDs in-flight. Had some wild values..... and corresponding difficulty when attempting nav launch.

I'm likely in a very small minority of users..... but some feedback.

[shellixyz]

I think when using the launch mode until it is not finished (!isFixedWingLaunchFinishedOrAborted) if TPA is configured the tpaFactor calculation should be consider the throttle to be at the minimum since during first moments of the launch the airspeed is really 0 (no wind) even at full throttle. Right now the PIFF factors are attenuated during launch just like in flight. It can make the launch difficult.

[digitalentity]

We need something smarter. Airspeed is low only during very short amount of time after throwing, not the whole launch. If we keep TPA boosted for entire launch it may cause the plane to destabilize after it gains airpseed.

[digitalentity]

What we can do is add a time constant (1-st order LPF) to throttle before using it to calculate TPA). It will help us account for acceleration/deceleration by creating a delay in TPA response vs throttle.

[shellixyz]

@digitalentity I like this idea :+1:

[digitalentity]

If people would throw some airplane logs at me (with GPS), I'll try to figure out a decent time constant default.

[shellixyz]

@digitalentity Not sure exactly what you will be looking for but here are some logs of my new wing. Consider that it was the first 2 flights and the rates and PIFF factors are only guesses but that's probably not what you are interested in. It is massive and I have some difficulty on launch. The 0.5 tpaFactor resulting of full throttle is not helping. I know I need to lower the throws and increase the rates but with this tpaFactor it makes things difficult.

ArrowV3_logs.zip

[digitalentity]

@shellixyz great, thanks! I'll be looking at speed vs throttle. Adding a filter to delay and smooth the response of TPA will definitely help you.

[digitalentity]

We should attenuate PIDs according to tuneSpeed / airSpeed, but we do it based on throttle according to tuneThrottle / actualThrottle. Idea is if we get actualThrottle filtered so it change at the same rate as speed, we will get better response from TPA.

First try: Orange - actualThrottle filtered with tau=1.3 sec, Grey - speed (from GPS, but should be in the ballpark with airspeed).

Looks like 1-st order lowpass filter is a good option. We'll need logs from more planes to figure out a sane default for tau

[shellixyz]

Nice fit ! For reference the logs are from a 1 meter span wing. 1600 grams AUW.

[digitalentity]

@shellixyz I figure tau should be more-less proportional to thrust/weight ratio. What's max thrust of your wing?

[shellixyz]

@digitalentity Max static thrust is 14.9N

[digitalentity]

14.9N = 1.52kg on Earth surface. So for your wing static thrust / weight ratio is ~0.95.
A few more data points and we'll get a good guesstimate for tau.

Actually, for your wing tau = 2.5 sec is a better fit. It also fits throttle reduction quite nicely:

[shellixyz]

The thrust/weight ratio is most likely on the low side for this wing. I have another wing a micro version FT Mighty Mini Arrow 49cm wing span, 360g AUW and 640g max static thrust so around ~1.78 thrust/weight. Most likely on the high side for this one. Unfortunately no GPS in this one. What are the thrust/weight of your FWs ?

speed (from GPS, but should be in the ballpark with airspeed).

The day of the logs there was ~20km/h head wind during launch.

[digitalentity]

What are the thrust/weight of your FWs ?

Usually about 1.5-2

Most likely the filter will have to be asymmetric, because deceleration rate is only proportional to drag, while acceleration is proportional to thrust - drag, but I don't want to introduce more parameters than necessary. I think one parameter to filter both increasing and decreasing throttle should be sufficient.

[shellixyz]

Deceleration rate should also be inversely proportional to the mass so proportional to drag/mass. One parameter is probably enough for an approximation. Nothing will replace an airspeed sensor. Acceleration rate during takeoff is in my opinion the most critical to estimate as close as possible.

[OlivierC-FR]

The small 70-90cm wings fitted with miniquad-class 2204 to 2306 motors, have a thrust/weight ratio between 1.5 and 3. Some extreme setups can go as high as 3.5, but that's not frequent. I believe a vast majority of planes are in the 1.0 to 2.5 range.

Could this TPA-curve thing improve the low pitch+roll authority during landing when the throttle is cut ?

[OlivierC-FR]

Excuse me for asking, but just to make sure, while the TPA for multirotors is only the reducing slope after the breakpoint, for fixed wings it's a straight line right ? Boosting below the breakpoint if I recall ?
Like, TPA=0.20 is PIDs=0.80 at 100% throttle, and PIDs=1.20 à 0% throttle ?

[digitalentity]

@OlivierC-FR current TPA is described in the wiki https://github.com/iNavFlight/inav/wiki/PID-Attenuation-and-scaling#airplanes. It boosts throttle below the breakpoint so it will also help with landings. However for steep dives without motors current implementation of TPA curve may cause oscillations because it will boost PIDs at high airspeed.

[OlivierC-FR]

Ok thanks, I had googled it and it sent me to an outdated page without the airplane part, my bad, didn't look hard enough.

[giacomo892]

@digitalentity I'll send you some logs of launches. Today Z84 was easy to launch as a baloon. Having a rather fast wind coming toward me. Hoping they are useful for your launch parametrization.

[devish1]

Keep in-mind the ability to opt-out of boosted / unboosted TPA. On my glider (no throttle or motor), this makes setup tricky. I tried the auto-launch again today on my glider, I've had to make adjustments to un-do all the issues related to alteration of PIDs, not even sure if I still corrected for the changes!

[digitalentity]

@devish1 you can always set TPA to 0% to disable it completely. Changes suggested in #2966 are not about boost, they are about delaying the TPA response. You can opt out of them with set fw_tpa_time_constant = 0

[wolfpackt99]

Per part 1. above (launch as message). Can we track that (part 1) separately as it seems this is now mostly on the other parts? Was going to enter a separate issue, but decided to search first and found this issue.

[danarrib]

I want to suggest a simple improvement on Autolaunch as well: A different buzzer pattern for when you ARM the FC with NAV LAUNCH enabled, but forget to raise the throttle stick.

So operator can know there's something wrong before toss the aircraft just to see it glide to the ground... Like this; https://www.instagram.com/p/Bj95s7yld4K

[shellixyz]

@danarrib I like this idea !

[giacomo892]

@danarrib eheh. with a so good launch you could have throttled up right after the launch :)

[stale[bot]]

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 should probably not be closed ?

[b14ckyy]

I have an additional idea!

What about an option to set the plane to loiter after the Autolaunch Timeout is reached without Stick input? My AR Wing was the first plane where I always was able to use Autolaunch on every start and it worked absolutely perfect! but mostly after launch I set it to loiter mode because I needed some time to put on my FPV goggles, took the transmitter and start flying FPV.

So instead to go to the flight mode set on the controller, it would be great to have an option to automatically launch and switch to loiter mode after given time or specific height instead of switching to the mode on the remote (that is Acro in my case), until the stick is moved. this could be a stage 3 Launch if you anticipate the 2 stage launch anyway.

[giacomo892]

@b14ckyy you can set position hold before the launch and after the timeout it will start to loiter

[b14ckyy]

@giacomo892 I know, I have already done that. But I need to remember that or the plane will possibly crash a few seconds after time-out if I forget that. A "fire and forget" solution as an option, would be nice though :)

[OlivierC-FR]

Making the launch procedure more complex would cause a lot more troubles and crashes than simply forgetting to set POSHOLD before launch I guess.

[giacomo892]

@b14ckyy well a plane should not crash after the launch is complete if it will fall back in ANGLE mode :) You can control it LOS and route it to a better direction before wearing the goggles

[b14ckyy]

It was just an Idea. Not a must have ;) after all this is an discussion thread.

[silenec]

Any progress on the stage2 launch phase? Li-Ion packs would be less sad :)

[Avegawanderer]

I really like the idea of increasing throws when launch starts. When I hand-throw my flying wing (1.4m, 1300g), it often starts unwanted roll turn due to reactive moment of motor and propeller. That turn sometimes leads to crash. If I increase servo throws, it helps, but that throws are not usable for a normal flight. From my point of view, it would be nice to have next launch stages:

1. Leveling. Increased roll and/or pitch throws (rate boost should be set by user). No TPA, user-set throttle level and climb angle. The purpose of this stage is to level UAV and gain some speed. Increased throws would help for low airspeed control. This stage should last until roll/pitch angle get close to desired values (nav_fw_launch_climb_angle for pitch and 0 for roll)) or timeout is reached.
2. Speed-up. This stage takes place after UAV is leveled. Normal roll/pitch throws. Enabled TPA. User-set throttle level and climb angle. This stage lasts for a user-set value [ms] or velocity threshold (provided by GPS or airspeed sensor). This stage is actually current autolaunch behavior.
3. Alti-gain (as proposed above). Purpose of this stage is to reduce stress on batteries while still gaining altitude. User-set throttle level and climb angle. This stage lasts for a user-set value [ms] or timeout/altitude threshold.

One more suggestion - CLI documentation should be updated to cleraly state that nav_fw_launch_velocity is NOT A DIRECT VELOCITY, but there MUST BE YAW TURN for it to trigger.
I spent a couple of hours on the field trying to figure out what's wrong with this threshold until looked up the code and realized that.