Feedback and assistance with new takeoff behaviour

Hi @Luke_Ionno,

Thanks for that feedback. Let’s get to the bottom of this twitch. First I need to understand where it is. This is what I see in the log:

I can see your alt hold is over tuned and rings after each input. This doesn’t sound like what you are describing though.

There are some attitude errors just on takeoff:

hmmmmm, it isn’t doing the normal takeoff ramp and is “not landed” just as it starts increasing the throttle. I may have seen this myself once but couldn’t reproduce it. Let me explore…

1 Like

Sure thing, in that log, observe the little pitch doublet right at the start of takeoff (timestamp 10:17:6.17).

Note that the initial response is out-of-phase - immediately after that, the attitude tracks rather nicely. This is very consistent with what the aircraft does, observed visually.

Also, if you look at the peak throttle (CTUN–>ThO), you’ll observe an unusually high initial value (~0.5) during takeoff, vs. the ~0.3 in “good” takeoffs (i.e. the 10X dataset). Again, this is observable by watching the aircraft.


Versus:

One unrelated question, I had been trying to tune the vertical acceleration loops using PSCD–>TAD vs. AD. Should I be using RATE–>ADes vs. A instead?

This is better because it is higher rate. So it is much clearer. If you turn on PID logging you will see the PID terms as well.

Depending on your tuning approach you may want to ensure your position and velocity loops are nice and stable so you don’t get mixed up between a velocity or position oscillation when tuning acceleration.

Ah, good point, it didn’t occur to me I could pick up the vertical accelerations in the PID messages. That would be very helpful.

I don’t want to derail the thread (more than I have, anyway - sorry!), but I will say the innermost loops (AccZ and rates) give me a hard time - both the setpoints and measurements are very noisy (except for yaw).

Can you describe exactly how you arm and takeoff when producing this problem?

Sure:
(1) Load a flight plan starting with a takeoff command.
(2) Boot, wait for GPS, etc. - doesn’t matter what mode.
(3) Switch to AUTO, and allow the aircraft to sit in AUTO for 2-5 minutes on the ground.
(4) Without changing mode hit the arm switch, to initiate an AUTO takeoff.

If the mode is switched to anything not AUTO at (4) and then switched back [immediately] before hitting arm, the twitch won’t occur (or at least, I’ve never seen it.)

Addendum: I have auto options set to allow:
-Arm into AUTO
-Takeoff without raising the throttle stick
-Arm on separate switch

It looks like you also move your throttle stick.

Good catch - not normally part of my routine, and not required to initiate takeoff, but knowing that I was performing a test that in the past had caused dynamic rollovers (and having a short supply of propellers), I was rolling in throttle after arming as a precaution if I had to exit AUTO quickly. (i.e. pull the mode switch back to STAB/ACRO, I wanted throttle set for flight.)

Could you show this problem again with:
LOG_DISARMED 1

I have a theory that the takeoff is being initialised when you switch to auto and your height drifts up and you are above your no-nav altitude immediately on takeoff. But I can’t see what is happening before you arm.

Sure, will do - just FYI, I’m down for a couple days, while waiting for replacement props (little oops, haha).

For the record, purely a mechanical issue, not a software one.

Well, I’m back up and running, tuned some of the ringing out of the altitude loops (thanks for the tuning recommendations @Leonardthall!) , set LOG_DISARM to 1, and got a fantastic example of navigation starting while still on the ground after a ~5-minute idle in AUTO (but disarmed) - it actually dragged a skid while maneuvering onto the outbound heading. (Yawed 45 deg. about the skid tip, haha!)

So, here’s the log, with 5 minutes of sitting idle:

And just for reference, here’s a normal no-idle execution, exactly the same parameters/plan/conditions:

Thanks Luke,

This confirms the bug and my fix. Can I get you to test to make sure you can’t reproduce the problem with the fix?

Ah, excellent news. I’ll definitely do some runs with the test build - might not be until next weekend, but I’ll let you know as soon as I have results.

2 Likes

@Leonardthall, well, bit of bad news - the -Cal1 firmware you PMed me just did the same early-navigation thing. I have a log, but it wasn’t set to log before arm - but exactly the same behavior as observed previously.

I had one good run, fresh boot, sat 5 minutes in AUTO (not armed), then performed a takeoff. After it completed the flight, I left it booted, and let it sit again - the second takeoff, it immediately started navigation (roll, pitch, yaw), while still on the ground.

No harm done, let me know if you want prearm logs, etc., I’ll repeat the test as required.

Edit: Now I’m doing the same test in 4.3.3-rc1, and it’s going well so far (roughly 6-7 iterations). Usually I would have seen it by now, but maybe probability is just messing with me, haha.

Nope, spoke too soon. Same thing, full-blown dynamic rollover, after 5 minutes sitting in AUTO, using 4.3.3-rc1.

I’m going to start a new thread for this, since it is definitely separate from the original discussion.

2 Likes

Hi @Leonardthall

Hope all is well. I just upgraded one of my backup aircraft from 4.0.3 to 4.3.3 to do some testing. Love everything about 4.0.3 (with Z jerk) but I’m desperate to integrate digital FPV with OSD so it’s time to move on.

I’ve got the aircraft flying very similar to 4.0.3 with a couple minor PSC tweaks, but the thing that jumped out at me was the new takeoff behavior. Scared the crap out of me the first flight as it jumped 4 feet in the air then fell back down two feet. I managed to find the TKOFF_SLEW_TIME parameter to mitigate the aggressiveness of the jump. Then I went to the forums and found this thread!

Thanks for starting this thread and explaining how the new takeoff behavior works and why you did this. I think this was a smart approach to decouple the takeoff behavior from the tuning parameters, and for many users this is better (especially for AUTO takeoffs and less experienced manual users). For our operations (regardless of pilot skill), I would say this new takeoff is better for 80% of takeoffs.

This new takeoff behavior is not ideal for the other 20% off our takeoffs though.

Here are some examples of situations (To clear the air, yes these are not recommended spots to take off, but sometimes there is no other option based on the circumstances) :
i) Taking off with an obstacle above the aircraft, say inside of a forest with a 10ft ceiling. Before we could slowly and smoothly bring up the aircraft up to a 1-2ft flight altitude. Now, no matter what the pilot does, soon as the throttle input hits a certain threshold (60%?) takeoff begins and the aircraft will jump 1-4 feet. This is going to make these situations very scary and risky.
ii) Taking off on very unlevel ground with heavy “looser” tuned aircraft. My favorite part of the old takeoff behavior was I was able to smoothly and slowly increase the throttle so the aircraft would raise the lower leg off the ground until the aircraft is level, then I would accelerate upwards. This made for a smooth takeoffs without the chance of overshooting pitch/roll causing oscillations.
iii) Taking off in very heavy winds. This could go both ways, for the majority people the new 4.3 behavior is probably better. Personally though I found the old behavior gave me more control. It gave me time to pitch/roll the aircraft into the wind before going airborne allowing a smooth straight up takeoff without any bobbles.
iv) Once you pass (60%?) throttle you are committed to taking off. You can’t abort your takeoff, you are going 1-4 feet in the air no matter what. I guess technically you could quickly switch into stabilize but that could be very sketchy depending on timing. Before in the old firmware you could stop the aircraft from taking off at any point. I can think of several situations where this would have been dangerous for us because seconds can matter. Besides the need to potentially abort the takeoff for a safety issue/malfunction, its also nice to be able to instantly abort takeoffs on very turbulent windy days when your trying to takeoff between gusts.

Before in 4.0.3 the user had a “connected” feel with the position controller from the second the motors started to spool up. Personally this was one of my favorite parts of ArduPilot. Our operations put us in some pretty ridiculous takeoff scenarios and the old behavior allowed us to comfortably takeoff where I know the new one will not. In the perfect world I wish it was possible to have a parameter to choose between the old and new behavior. Like I mentioned for the majority of takeoff scenarios I think the new behavior is great. That being said for our operations, if I could only have one it would be the old behavior because of new limitations on takeoff areas.

Chris

Hi @DroneUnit,

I would need to see some logs to understand what you are seeing however my testing showed very different results over my test aircraft.

The first point I would make is I found the minimum take-off altitude extremely consistent. If I just pushed the stick up very slowly and then let it go as soon as I felt the throttle start to slew up I found the final height was within a few cm each time. So I think your 1-4 feet is a bit of an exaggeration. Your final height may be somewhere in that range if you use my approach but it should be pretty much the same height each time.

Looking at each threshold I could imagine that if someone had set high vertical accelerations and climb rates, they would get a higher minimum height. I haven’t seen such a log yet so I would be interested to see your logs.

I may be able to cater to your needs by adding a maximum throttle to the take-off parameters. This would let you set it just above your maximum hover throttle for extremely low minimum take-off altitude. This would give you the ability to move it lower than your hover throttle and get the old behaviour. This would also help tune the “pop”.

On each of your points:

i) Given the consistency of the new take-off I believe the new approach is safer for the majority of aircraft and pilots. Most aircraft will see something like a 1 ft take-off altitude, maybe with a small overshoot… Every time.

ii) If you set the slew to be 5 to 10 seconds on this “looser” aircraft, the autopilot will do exactly this on every launch and won’t rely on the pilot to understand this. It also removes the danger of any roll or pitch input causing loiter to move sideways and cause a tip over during this slow takeoff.

iii) In Alt_Hold the old take-off would let you lean into the wind before you left the ground. I agree you that the new version is a clear improvement in every other mode.

iv) Yes as soon as you are out of the dead band you are committed to take-off. I considered an abort with low throttle but this could result in an aircraft falling from a small height if you catch it just before it detects take-off and I couldn’t work out a way of doing this safely. It is worth noting here that the old approach declares the aircraft flying as soon as you are out of the dead band too. This means that the old approach requires the pilot to go through the full landing sequence (the autopilot must detect landing) before they can shut down. The difference is that the position controller is fully engaged in loiter so any roll/pitch input can cause a roll over during this time.

The one area where the new approach may be clearly worse than the old version is if the aircraft has one leg stuck in the ground such that any take-off attempt will cause the aircraft to tip over. A very, very, slow take-off using the old approach may give an experienced and alert pilot an opportunity to prevent the tip over. I term build up will get most pilots in this situation though.

If you can provide some logs showing your 4ft minimum take-off I may be able to offer some advice on how to get the most out of the current code.

Thanks for your feedback and input. A take-off throttle max parameter may be the outcome.

3 Likes

Thanks for the feedback
.
You now have me a little worried. I hadn’t thought about a leg stuck situation yet. This has happened to me a couple times and thankfully I have been able to save it both times (once taking-off on a small boat, yikes).

In a leg stuck situation would the attitude controller prevent the aircraft from flipping (throttle would be limited)? If so, would the height controller get stuck in a loop, or is there something that would cause it to exit the throttle ramp?

Let’s say the aircraft was fixed to the ground and you tried to take-off. From my understanding the throttle would ramp from 0->100 over the TKOFF_SLEW_TIME. What happens when the throttle reaches 100%. Will it:
i) stay at 100% (because it hasn’t detected vertical acceleration)
ii) or does it declare the aircraft flying as soon as it hits 100% even without vertical acceleration detection?

I think your Max Take-Off Throttle parameter sounds like an amazing improvement, not only for behavior but also potentially safety.

I am just speculating, but the Max Take-Off Throttle parameter may be very useful because it will allow users to use shorter slew times for faster take-off BUT the “hop” could be minimized leading to a more connected feeling.

The other potential safety benefit here I see is you should be able to abort a takeoff (assuming the Max Take-Off Throttle is set near or lower than hover throttle) hopefully without any flips.

Just thinking ahead, I think it would be easier for people to tune takeoff behavior if the TKOFF_SLEW_TIME was always based on a 0->100% ramp even if the Max Take-Off Throttle was set to say 50% (ie motor rpm acceleration is only dependent on one parameter, TKOFF_SLEW_TIME). Not sure if this would be possible though?

I guess I should clarify my 1-4ft comment. I haven’t seen 4ft since my very first takeoff, I am guessing this may have been due to GPS Alt drift. The throttle ramp “hop” typically only causes a 1.5-2.5ft hop before the aircraft’s altitude drops down a little. In the log below, I quickly blimp the throttle above the dead band then return it to the dead band. In the log the first takeoff is with a 2sec SLEW and the second is with a 10sec SLEW. Regardless of the slew I get about a 1.5-2.5ft hop. Couple video to show this below
Log: 2023-02-26 11-32-57.bin
Video (Slew 2sec, 34MB): Takeoff Slew 2s.mp4
Video (Slew 10sec, 39MB): Takeoff Slew 10s.mp4

It declares the aircraft is flying so you get normal Alt_Hold behaviour. So the maximum time you can be in this state is TKOFF_SLEW_TIME.

Yes, I think so too.

Maybe, maybe not. The old behaviour will build the throttle up quiet quickly too. A leg being stuck has always been a big risk for any aircraft. So even if it drops back to Alt_Hold, the I term will do the same thing if the pilot isn’t very lucky.

Yes, I agree. This defines the throttle slope. It defines the time between min and max throttle if you were taking off in Stabilize.

Yes, that is more what I would expect. Looking at your parameters you have:
PILOT_ACCEL_Z - 450 cm/s/s
PILOT_SPEED_UP - 550 cm/s

These are high. This makes for a later detection. Your aircraft also can’t keep up with the deceleration and overshoots more than it should. I would test:
PILOT_ACCEL_Z - 250 cm/s/s
And see how you feel about that response. I understand why you might like the higher acceleration but it makes the aircraft work a lot harder and tends to increase altitude errors and overshoot problems.

The Max Take-Off Throttle parameter would really help with your choice of parameters and solve the take-off problems related to your high PILOT_ACCEL_Z preference.

Would you be happy to test some code for me?

1 Like

@Leonardthall
I understand PILOT_ACCEL_Z - 250 cm/s/s would reduce potential overshoots. In the real world I probably rarely exceed 100cm/s/s on the sticks based on the style of flying we do so it’s not really an issue. The high 450cm/s/s rate is needed when we are flying FPV and we have a make a last second dodge up or down haha (usually a tree branch).

My altitude controller gains are definitely low. Due to our fairly soft gimbal dampers and ever changing payloads I’ve found it just easier to keep the tune it loose since as there is never any chance to tune on set. The loose tune also makes any vertical movement on our filming camera look more organic and less jerky as a bonus!

I would be more that happy to test some code. I don’t have a small / cheap based ardupilot copter at the moment though so I won’t be completing a “stuck leg” test haha.

Chris

2 Likes