Takeoff flight mode vs. takeoff in a mission, Plane 4.0.6 - CLEARLY DIFFERENT!

I’m learning how to use rolling Auto Takeoff on my taildragger Volantex Ranger EX. I’ve used both takeoff flight mode and takeoff in a mission. might be a coincidence, but takeoff in a mission worked SIGNIFICANTLY better.

using takeoff flight mode, the plane tends to turn 10-20 degrees to the right during takeoff. it levels out and climbs in a nice straight line, but aiming a little to the right. tricky if there are trees there (there are).

I’ve seen this 4-5 times now, so I think it’s repeatable.

but the one time I did takeoff as the first point in a mission, it worked perfectly. climbed with a nice straight heading.


Arduplane 4.0.6

I caught it red handed! Takeoff as a flight mode and Takeoff as the first item in a mission are quite different. I don’t yet understand why or what all the differences are, but they clearly are different. Perhaps Takeoff flight mode is best suited for hand launch, while takeoff in a mission is best for rolling takeoffs? But I’d like to better understand the differences.

I could not film it, but a takeoff in a mission follows a straight heading far better than in Takeoff flight mode.

On the Ranger EX I set set up tail dragger mode to keep the tail down longer and steer better on the ground. I found it wasn’t holding the heading in take off mode until it got some stable airspeed and keeping the tail down so it would steer on the ground helped a lot. It’s still not perfect.

it would be really helpful to post a flight log with both takeoff variants to help track down the issues you’re seeing.

What is you param :

  • TKOFF_LVL_PITCH in comparison to your mission pitch command ?

Take off mode take in consideration LEVEL_ROLL_LIMIT. Did you notice it in the doc

LEVEL_ROLL_LIMIT: Level flight roll limit

This controls the maximum bank angle in degrees during flight modes where level flight is desired, such as in the final stages of landing, and during auto takeoff. This should be a small angle (such as 5 degrees) to prevent a wing hitting the runway during takeoff or landing. Setting this to zero will completely disable heading hold on auto takeoff and final landing approach.

Difference in throttle seems to be take off in mission use TKOFF_THR_SLEW_RATE : https://ardupilot.org/plane/docs/parameters.html#tkoff-thr-slew-takeoff-throttle-slew-rate
Whereas take off mode seems to not use it or use THR_SLEWRATE instead as this mode could be enable in flight !

Good suggestion, but TKOFF_ROLL_LIMIT is at it’s default of 5 degrees. TKOFF_LVL_PITCH is 20 degrees.

my real concern is that the two methods of autotakoff are different, but I can’t find documentation that explains these differences. At the very least, tkoff_thr_slew_rate is honoured in missions but not in flight mode. Perhaps there are also other differences.

I agree, but unfortunately I don’t have the tlog from that day as the laptop was not connected at the time.

what about onboard logs…?

Here are the onboard logs for two flights that day. first is using auto launch flight mode. second has the tests from the video above followed by takeoff in mission mode, which was much better.


at a rough glance i can‘t spot any major divergence between those two takeoffs. could you be more specific about the differences you‘re referring to?

watch the video at the beginning of this thread - throttle slew rate is honoured in one mode but not the other. I suspect arduplane handles other parameters the same thing way.

ok, this imho is expected behaviour though.
this is the parameter group that explicitly refers to TAKEOFF as a flightmode: https://ardupilot.org/plane/docs/parameters.html#tkoff-parameters

in an alphabetically ordered full parameter list those are hard to separate from plane’s basic TKOFF_ parameters which refer to TAKEOFF as a mission item. it might be helpful to add some verbosity to the documentation.

Hi folks. @vierfuffzig has posted an issue for developers to track the TAKEOFF Mode vs Auto Takeofff behavior:

Regarding the turn on launch, this is actually a long standing problem. It comes from not relying on heading-lock instead of GPS ground/heading track due to it not being reliable yet and thus relying on gyro and compass which take a nasty G-shock and current/magnetic spike at full-throttle on takeoff. I have a pull-request that I posted a few months ago to address this (for auto takeoff) by using a virtual waypoint far away that it tracks towards during the climb.

thanks tom @MagicRuB for looking at this.

@dale2020 what exact firmware did you test TKOFF_THR_SLEW with? your video shows it working on takeoff mission item only, whereas it seems to not have any effect at all in current master.

edit: nevermind, found it. (4.06)

I appreciate that this is being looked at. couple things:

  1. I showed how TKOFF_THR_SLEW behaves differently in the two types of TAKEOFF. that’s true, but it’s not just that parameter - that was just the easiest one to demonstrate in the video. For example, as my plane is a taildragger and the elevator is supposed to keep the tail pinned to the ground during takeoff, but only does so with takeoff as a mission item. And I’m sure there are other differences.

  2. knowing that there are two forms of takeoff that are activated differently is actually a benefit. I keep both of them programmed to different buttons on the remote because one is good for a rolling takeoff and the other is best for a hand launch. I hope the solution to the issue I’ve raised evolves into two distinct flight modes - TAKEOFF1 and TAKEOFF2.

Thx for the post. I’ve been lurking and hoping this would come to light.
I was really disappointed that takeoff mode ignored my elevator tail dragger setting. I don’t always fly auto missions and will use this mode if it works. When the autopilot works, the takeoffs are very good.
Another ‘takeoff’ related difference I’ve noticed is FBWA takeoff will activate the tail dragger elevator (with channel switch), but will not operate the rudder to stay on course like mission or takeoff mode. To test, I picked up the tail and moved it from side to side.

@AndyG for ground steering you need some speed:

STEER2SRV_MINSPD - This is the minimum assumed ground speed in meters/second for steering. Having a minimum speed prevents oscillations when the vehicle first starts moving. The vehicle can still drive slower than this limit, but the steering calculations will be done based on this minimum speed.

My experience with 4.10dev shows ground steering works with FBWA

This seems to still be an issue in 4.0.9 and 4.1.0 beta. I opened another thread provided below where I included bench test and in-field examples between the two methods of taking off. It would be nice to have motors ramp up and respect the TKOFF_THR_SLEW parameter. Any word on if this is being addressed?