That shouldn’t cause the jump. It is more likely that TKOFF_SLEW_TIME is set too low.
Can you share the log you posted the picture from?
Hi @Leonardthall,
Today I updated the firmware on that same copter to V4.3.1 and recorded some short flightlogs. I think the copter takes off fine and there is no problem. Adjusting the TKOFF_SLEW_TIME from the default 2 to 4 ‘slows’ the take-off procedure so that works fine. I could take it further in slowing it down but on windy days that could only cause trouble.
Anyway, I hope these two logs help.
TKOFF_SLEW_TIME = 2
https://drive.google.com/file/d/1BOaD8KykuRva5o10Vs0Jwc_QrmWaHUiH/view?usp=share_link
TKOFF_SLEW_TIME = 4
https://drive.google.com/file/d/1krg_lcS2Zhp0vlC-T8SIQM2MkWG0x0XL/view?usp=share_link
On the contrary, with a less twitchy throttle, reducing from 2 to 1.5 seconds’ slew time made for a crisper takeoff that I prefer.
I think the tuneability is a nice touch.
Both logs look fine and seem to be working as I would expect. You are also running terrain following and that adds some complexity to the post takeoff behaviour that confused me for a minute.
I don’t understand where this question came from as you seem to be happy with this now.
1 Like
My apologies - I didn’t mean to imply there was something wrong. I think it is just that I didn’t know there was a change in the code and noticed a change in take-off behaviour when moving from FW V4.2.3 to V4.3.0. The take-off resembled a quick ‘jump/hop’ but everything was fine so didn’t think much of it until someone else on the forum was asking about this I confirmed I was seeing the same thing.
The other question was only triggered as I didn’t know it was there until I was reading this thread and wondered if I needed to set it to a value. (as you stated - it isn’t required unless you want a specific altitude).
Anyway, I think it works nicely and the extra controls allow for configuring the take-off to the copter and user’s preference. So, nice work!
1 Like
Could I ask anybody interested in this thread to provide suggestions or advice on what we should put in the wiki (and perhaps where) regarding the setting of TKOFF_SLEW_TIME. Or is the parameter description enough?
1 Like
I took a look at the wiki and it’s categories. It’s not a first time setup parameter, but it is a tuning parameter or an advanced configuration parameter maybe. i couldn’t find any good category in advanced config which could include this one, except tuning.
Although, when looking through the sub categories if tuning, I can’t really find a place to put it. Maybe a category for fine tuning could be added. And to that you could add all small parameters that you can use to make small adjustments to the flight behavior. It feels like a parameter you could put with the loiter parameters, but since it’s also applicable in Alt.hold maybe that will be confusing.
I think a fine tuning category would be a great place to for such parameters. But that’s just me.
Also, under the First time setup > configuration > configure motor range. It is a “(optional)” behind configure motor range, I don’t think it should be optional. It’s really important to set the min throttle high enough and make sure that all motors spin when armed. I think you should remove the optional if you guys agree with me that is
1 Like
Not exactly traditional Christmas morning activity, but I finally had a chance to get some apples-to-apples comparisons of 4.1.5 takeoffs, versus 4.3.2 takeoffs, and I seem to have gotten lucky, because I got some interesting datapoints. Four log files can be found here:
Background
This is using a 3DR Iris-size quad, nothing special (10"x4" props, 3s packs, 3.1 lb. AUW). I’m running an Orange Cube flight controller. I think the tune is OK/decent (open to feedback). I’ve been running it for over a year with 4.1.5, though, so lots of time to observe any quirks, etc. It flies very consistently, on arbitrary flight plans. It has always exhibited noticeable barometer drift, but no different than I’ve experienced on PixHawks, etc., so I’ve operated under the assumption this is normal.
I am using a separate arm switch on my radio, and allow arm direct to AUTO. I keep the aircraft in STAB until I’m ready for takeoff, then switch to AUTO and immediately throw the ARM switch. I do not use rudder-stick arming.
When switching to 4.3.2, I disabled the AGL sensor to clear the pin 103 prearm check conflict discussed elsewhere. I also set the TKOFF_SLEW_TIME to 30 seconds.
Flights:
The 4.1.5 flight is typical, i.e. not a cherry-picked ‘perfect’ flight. During takeoff, the throttle output never climbs above 35%. Visually, the takeoff is smooth, with no abrupt changes in altitude, attitude or motor tone.
The first 4.3.2 flight was off a fresh boot - it smoothly ramped throttle on the ground, then jumped a little, and immediately rolled left quite aggressively, before going wings-level - I took over and landed in ACRO. I had WP_NAVALT_MIN set to 0.25, and wondered if that was allowing it to go open-loop for the first quarter-meter, so I set that back to the default of 0.
The second 4.3.2 flight was off a fresh boot - it skipped the throttle ramp, jumped, and pitched aft slightly, but nothing alarming enough to intervene. Otherwise, it completed the pattern normally. Throttle output hit ~90% during takeoff.
The third 4.3.2 flight was not power-cycled - it did a very brief throttle ramp, but then did NOT jump perceptibly. It completed the pattern normally, except for a low-battery failsafe a few inches before touchdown.
Summary
4.3.2 flights show inconsistent takeoff behavior - ramps or not, large throttle output spikes, and attitude setpoint changes. Both the roll left and pitch aft were commanded (i.e. they show up in DesRoll/DesPitch). No parameter changes were made between the second and third flights (just restarted the flight plan), but the behavior was markedly different, with the third takeoff looking much more like 4.1.5, both visually and in log reviews. The first two 4.3.2 takeoffs were visually abrupt (despite a steady initial throttle slew on the ground on the first one), and the attitude changes were unsettling. 20 deg. of commanded roll a foot off the ground gets the heartrate up, haha.
Lastly, not related to the takeoff behavior, but I notice I’m getting attitude overshoots in 4.3.2, whereas 4.1.5, I thought I was doing pretty well. The weather conditions are practically identical between flights, possibly slightly worse winds for the 4.1.5 flight.
Regards,
-Luke
Good work Luke
I can see in 4.3.2#1 - Jump, Rolled Left-anon.log there is some latitude drift up to and including takeoff.
The GPA.Delta is a bit inconsistent in all flights.
GPS HDOP actually worsens by the time you launch and in flight which is odd.
The other 4.3.2#2 - Jump, Pitched Up-anon.log is similar in regard to GPS figures, so maybe there was some position drift going on there too that I didn’t notice.
The first and the last logs, the good ones, are where HDOP is most consistent.
Try setting GPS_GNSS_MODE to use just two constellations, GPS and Galileo should be fine where ever you are, a value of 5. You can add SBAS if in the USA
You could also set FENCE_ENABLE,1 which some people find annoying, but it does mean you want be arming and flying until the GPS position has settled down and Home can be set.
It would be nice if you can do a couple more tests with the above changes (GPS_GNSS_MODE and FENCE) and see if the same behaviour occurs.
EDIT:
The transmitter could benefit from a stick calibration if it allows that, and then you’d have to do a RC calibration in Arducopter too. There’s nothing really wrong, just the at-rest positions of the sticks are different. It might not help anything.
I have to spend a bit more time on this but why did you change the default takeoff time?
apples-to-apples would be 2 to 4 seconds, not 30.
The takeoff detection is triggering off of noise and you are giving it a lot of time to find that noise spike. You also don’t have much noise filtering ether:
INS_ACCEL_FILTER 20 Hz
You don’t have fast logging so that is slowing me down a little.
I need to spend some more time to look at the lean over issue but I should get some time this afternoon.
Thanks for the quick responses!
Leonard, I set TKOFF_SLEW_TIME to 30 based on your earlier comment a couple weeks ago in response to Axel and I both noting that we hover at fairly low throttle settings. 2-5 seconds had previously produced very abrupt takeoffs last time I tried 4.3.0, so I was trying to head that off. It sounds like the noise trigger explains why sometimes it would ramp, and sometimes it would just go straight for takeoff; would it also be responsible for the occasional 90% throttle punchout?
Fair on the other points, I had never had functional issues relating to the filter settings, so I had left them well enough alone. Sorry about the fast logging - I can redo the flights, if it would help.
As far as the GPS, yes, I was flying no-GCS - I would wait for the lock tone in AUTO mode, and then switch to arm. All the usual pre-arm checks are in place, so my practical experience was that an arm-to-AUTO isn’t allowed without home being set, GPS HDOP below threshold, etc. I should be able to get the GPS redo flights in this week. I’ve got to ask, did something change in the takeoff navigation logic? I’m probably close to 100 AUTO takeoffs on 4.1.5 on this airframe/GPS, and I can’t recall ever having aborted due to maneuver like that before - same test location, etc., so there’s no way I was just GPS lucky every time, haha!
I’ll take a look at the stick cals, I see it too, that’s an odd one, I’m 99% sure I’ve got my transmitter rigged no-trims, symmetric throws. On the other hand, it’s a PPM–>FRsky retrofit setup - that might be as good as it gets.
OK, I’m preparing a takeoff-hover-land-repeat flight plan.
I’ll set the GPS up as Shawn requested - for the logging, I’m assuming I should toggle bits in the LOG_BITMASK to collect fast attitude and IMU?
Any requests for a better value for the INS_ACCEL_FILTER? Take that down to 10 Hz, perhaps?
Ok, changes made:
FENCE_ENABLE = 1 was 0
GPS_GNSS_MODE = 7, was 0 (in the US, so SBAS is on)
TKOFF_SLEW_TIME = 4, was 30
INS_ACCEL_FILTER = 10, was 20
LOG_BITMASK: enabled fast attitude, fast IMU logging
LOG_FILE_DSRMROT = 0, was 1 (I’ll be repeating a very simple flight plan, I want one log, not many short ones)
Flight plan is now just a takeoff, followed by a landing. 10 iterations, manually rearming after each landing. Log here:
Observations:
Much better, overall. Minimal jumpiness observed.
There was a distinct vertical oscillation, most pronounced on the first flight, but present on all flights, particularly during descent. Obviously, filter/gains related, lots of ringing in the Z acceleration loop, will be addressed by retuning the vertical loop.
There was a roll-left event on the 8th iteration. Not severe, but because it starts when still in contact with the ground, it looks like impending dynamic roll-over, until it sorts itself out. This did occur during slightly higher HDOP values. Setting WP_NAVALT_MIN to a non-zero value should help with this, right?
…Ok, so I figured I’d try sorting out the pogo oscillation (drop VELZ_P and ACCZ_I for a start), and just for kicks, see what WP_NAVALT_MIN = 1.0 would do (I know, breaking the rule, change one thing at a time). On takeoff, the darn little guy tried to kill me, haha! Got light on the skids, and then pitched up 30 deg. Please excuse the subsequent panicked pilot-induced oscillations - got it worked out in the end. The HDOP was quite good during all that. No spurious GPS velocities, etc. - it was 100% commanded from the nav loops, as far as I can see.
Log here:
More tests to follow, setting NAVALT_MIN back to zero for now.
Edit:
Changes:
Returned WP_NAVALT_MIN back to the default of 0.
Seven more iterations of the takeoff/land cycle. Log here:
Imperfect Z-loop tune, but at least the motors aren’t audibly oscillating any more. Still, on the 7th iteration, I got a 15 deg. roll left during takeoff. The target/actual positions, velocities and accelerations all seemed spot-on, right before DesRoll spikes left.
Sorry for the data overload here, I really appreciate the expert eyes on this.
Stop testing, I have found a bug when PSC_VELXY_FF is not zero. This is what is causing your pitch over.
I will get you some custom code to test if you are happy to do so.
1 Like
Sure, I’d be happy to give it a go. What source file is this in, I’d like to take a read-through, just out of curiosity.
I will have some more info and graphs in the PR shortly.
1 Like
This is the PR to fix the issue where I reproduce the lean over problem.
@Luke_Ionno Thank you very much for testing and discovering this problem!!
1 Like
I can see you have tuned up your Z controller quiet well but the reduction in INS_ACCEL_FILTER has meant we need to back it off a little. I can see you already worked this out:
My normal starting point for your aircraft would be:
PSC_ACCZ_P 0.25
PSC_ACCZ_I 0.5
So you are tuned pretty tight given you are 4 times that. I would hope you can fix the problem by dropping back to the defaults of:
PSC_ACCZ_P 0.5
PSC_ACCZ_I 1.0
I hope that with those parameter adjustments and the bug fix in the code you should be up and running nicely.
1 Like
Thanks so much, I’ll try and get some testing in on the patch today or tomorrow. I just spent a couple batteries dialing in the ACCZ loops, after much exploratory tuning, my current gains are:
PSC_ACCZ_P 0.5
PSC_ACCZ_FF 0.5
PSC_ACCZ_I 0.2
Increased I seemed to produce some out-of-phase ringing and overshoots during transients.
In any case, once I get some tests in, I’ll post results.
Ok, some good news, and some ‘meh’ news:
First, Leonard, thanks for the test build - I loaded that up, set WP_NAVALT_MIN = 1 (go big || go home, haha), and repeated the 10X takeoff/landing test. Absolutely perfect, no wonkiness. Log attached, just for the record:
Buoyed by success, I then tested sitting unarmed in AUTO for 2-5 minutes, and then arming/taking off. With 4.1.5, I had learned by bitter experience and broken props that this would often (enough) result in dynamic rollovers - regardless of WP_NAVALT_MIN, etc., it would start giving attitude inputs immediately after arming (i.e. while still on the ground). The workaround was just to do a quick mode switch just before arming - I suspect most people are leaving the arming options alone, thus they can’t arm while in AUTO, and the problem never manifests.
This produced some twitches - nothing catastrophic, but on takeoff, the throttle would audibly surge, and it would do a pitch perturbation. It wasn’t consistent in magnitude, but out of three attempts, I got it to do it each time. Compared to the super-smooth takeoffs when doing a mode switch right before arming, it was very noticeable. I wasn’t able to get it to actually do a dynamic rollover, unlike 4.1.5, but maybe I just didn’t get lucky/unlucky (or I wasn’t patient enough).
A couple example logs attached. #1 is more pronounced, #2 was less so, but it was still visibly/audibly apparent. In both, you can see the attitude setpoint moves around a bit, and the throttle spike is larger than any of the takeoffs in the 10X log.
I had always assumed this was an integrator windup of some sort. It never happens if you arm within say, 10-15 seconds of switching to AUTO, and the odds of occurrence go up with time spent unarmed in AUTO. Not exactly the original issue under discussion, but it does produce similar symptoms.