I have opened this thread to discuss the new takeoff options and behaviour. Please post here if you have questions or are experiencing issues.
This is operational for any Altitude Controlled mode. So it does not change Stabilize or Acro.
Before the new takeoff throttle code was added with the TKOFF_SLEW_TIME parameter, the throttle response was determined by a combination of:
Altitude Hold tune (PSC_POSZ_P, PSC_VELZ_P, PSC_ACCZ_P, PSC_ACCZ_I)
Vertical Speed (PILOT_SPEED_UP or WPNAV_SPEED_UP)
And in earlier versions (Pre 4.0 I think) PILOT_TKOFF_ALT
So the takeoff behaviour was practically impossible to tune without compromising in flight performance.
The new code uses a throttle ramp rate based on the time taken to move from 0% to 100% throttle defined by TKOFF_SLEW_TIME. While ramping the throttle the aircraft looks for vertical movement that would indicate that the aircraft has taken off (or it reaches 100%). After this it uses the normal in flight behaviour. If the aircraft thinks it has taken off but hasn’t you get the same performance as you would have before 4.3.
It should be apparent in the logs I sent you for the internal error issue. The craft made the little jump there to. I can provide a log and video when I test your new version with the new controllers, if it still behaves like that on the new version.
Your last log took off in Stabilize. I assume that is fine?
I went back and found an earlier log that you were in Alt_Hold and I think I see the problem:
You have a hover throttle of about 14% and you have TKOFF_SLEW_TIME set to the default of 2 seconds. TKOFF_SLEW_TIME is the time to reach 100% throttle. Because you take off at such a low throttle setting the throttle is reaching 21%, maybe even a little higher, before takeoff is detected and confirmed. I think this is popping you off the ground a little more aggressively than you want.
I would suggest trying TKOFF_SLEW_TIME 5 or 10 seconds. That should have you off the ground in about 1 second.
Maybe it’s because of the low throttle. It didn’t happen on 4.2.3 but I wouldent say it’s an issue really. As long as it’s predictable it might be good to come off tje ground quickly
I would be interested to see how you feel about the TKOFF_SLEW_TIME. I put it in there because I wanted to be able to tune the takeoff behaviour just the way I like it. I would try 5 and 10 like I suggested and see what suits you best.
I’ve rolled back to an earlier firmware (due to the pre-arm check issues already being looked in to), but I can load up 4.3 again and get some logs; I had tried TKOFF_SLEW_TIME up to 5 seconds and it was still pretty jumpy, but like Axel, I hover at pretty low throttle settings (~20%, if I recall correctly), so that may be the unifying factor here.
Yeh, with very low hover throttle it will take off very quickly. I have tested between 0.1 seconds (basicly just punches to full throttle imediatly) to 30 seconds (it is a very slow and gentile wind up before takeoff).
Before the new takeoff throttle code was added with the TKOFF_SLEW_TIME parameter, the throttle response was determined by a combination of:
Altitude Hold tune (PSC_POSZ_P, PSC_VELZ_P, PSC_ACCZ_P, PSC_ACCZ_I)
Vertical Speed (PILOT_SPEED_UP or WPNAV_SPEED_UP)
And in earlier versions (Pre 4.0 I think) PILOT_TKOFF_ALT
So the takeoff behaviour was practically impossible to tune without compromising in flight performance.
The new code uses a throttle ramp rate based on the time taken to move from 0% to 100% throttle defined by TKOFF_SLEW_TIME. While ramping the throttle the aircraft looks for vertical movement that would indicate that the aircraft has taken off (or it reaches 100%). After this it uses the normal in flight behaviour. If the aircraft thinks it has taken off but hasn’t you get the same performance as you would have before 4.3.
So it didn’t exist at all prior to 4.3. I could look at a log and tell you about what it would need to be to get similar performance. I would just play with that value between 1 and 30 and see what you like.
Yes, that was a big risk for large aircraft with heavy loads, they could take a very long time to get off the ground. If you happened to have a small movement in your gps as you were taking off the aircraft could start to tip over.
For normal operations I use a slower TKOFF_SLEW_TIME to ensure I don’t scare people but if I am on a moving platform or operating in strong winds I tend to reduce it (I like it a little faster myself).
Given the tune-ability of this, I can see utility in a script that, at the flick of a switch:
Creates a mission
Inserts a takeoff command and hover waypoint above home (present position, really) at a user-selectable altitude
Selects auto
Arms
Awaits hover altitude (mission complete)
Selects loiter (or a user defined end-state mode)
I have a new Copter as of today that would be good for testing this (docile EDU-450). Unfortunately, if I don’t do it tomorrow, I probably won’t get to it for at least a week.
EDIT:
Am I misunderstanding that this is not just an AUTO mode feature but could be enabled for any arm-able mode?? I reread the posts, and perhaps I misunderstood from the start…
Got it. The script wouldn’t be quite as useful as I thought, then, but it still might be worth exploring as an option for those hesitant to takeoff using their thumb on the throttle stick (of course, a good tune is still a requisite…).
If you set PILOT_TKOFF_ALT to your desired takeoff altitude you will get the equivalent of what you describe if you take-off in Loiter. You would have to arm and as soon as you lift the throttle above 50% you would take-off to PILOT_TKOFF_ALT. It improves safety a lot as it ensures a very consistent departure from ground contact.
I will endeavor to test that case tomorrow, then, rather than putting effort into a script. My thought for a script was actually quite similar to this behavior, and it’s good to know that it’s already there!
With PILOT_TKOFF_ALT at 3-4 meters, TKOFF_SLEW_TIME=2 (default), and a hover thrust of approximately 25%, my EDU-450 is behaving very nicely. LOITER mode takeoffs are smooth and consistent. Nice feature!
I’d need to test it but perhaps the takeoff ‘jump’ was caused by the PILOT_TKOFF_ALT default to 0? Also, the TKOFF_SLEW_TIME is/was set to 2(default) with the range defined slightly different to the suggested values that make more sense perhaps for a larger copter.
When I’m next out I’ll adjust the params as @Leonardthall has suggested and see what things look like. Either way, for me it was not really a problem - just a change in how the copter took off.
