Slow throttle response in AltHold and Loiter

ArduCopter Copter 4.0
1

Hi all,

I am have difficulty figuring out how to get our aircraft to be more responsive and accelerate faster vertically upward in AltHold and Loiter. The aircraft has plenty of power (over a 3:1 power ratio). In stabilize mode the aircraft is responsive and accelerates quickly (as expected).

In AltHold and Loiter no matter what gains/parameter I change it always seems to feel like there is a 0.5s delay in the vertical climb (I realize there is actually no delay, it just due to slow desired acceleration)

I have tried playing and setting all these gains very high with no luck:
PILOT_ACCEL_Z = 3000
PSC_POSZ_P = 3
PSC_VELZ_P = 8
PSC_ACCZ_P = 1.25
PSC_ACCZ_I = 2.5
PSC_ACCZ_IMAX = 800

The most obvious parameter that I would think would affect this is PILOT_ACCEL_Z. As you can see in this test I set it very high (3000). This is the only parameter that seems to really make a difference, but the strange thing I am noticing is once I set this any higher than roughly 300 there seems to be no change and when I look at the Desired Vertical velocity curve, it also shows that the aircraft doesn’t seem to accelerate any faster once I go higher than 300. Any ideas? Not matter what I set PILOT_ACCEL_Z or no matter how high I set the gains, the aircraft will not vertically accelerate faster than 3.0m/s/s on the dot. Is this something hard coded or is there some other parameter that is limiting this to 3.0m/s/s?

Log: https://www.dropbox.com/s/wlwc72brlqr4j2e/00000325.BIN?dl=1

2

PILOT_SPEED_DN and PILOT_SPEED_UP

3

Unfortunately those have no affect on acceleration. Those only affect max vertical velocity.

4

I think pilot_accel_z range is 50-500, can’t go higher.

You could try PSC_ACCZ_FF, it is feed forward, should make it more reactive. Range 0-0.5

5

It does say that’s the safe range. Its strange forcing it above 500 does not seem to do anything though. I tried changing PSC_ACCZ_FF all the way up to 0.5 but it had no effect.

6

Your CCW motors are all working harder the CW motors, so there’s a physical yaw bias that the flight controller is fighting. Twisted arms or motor mounts…

Set
ATC_THR_MIX_MAN,0.5
this might help.

These could go back to:
PSC_ACCZ_I,0.56
PSC_ACCZ_P,0.28

And you should set these:
BATT_ARM_VOLT,22.1
BATT_CRT_VOLT,21
BATT_LOW_VOLT,21.6
BATT_FS_CRT_ACT,1
BATT_FS_LOW_ACT,2
MOT_BAT_VOLT_MAX,25.2
MOT_BAT_VOLT_MIN,19.8

1 Like
7

Thanks Sean.
ATC_THR_MIX_MAN - Changing this won’t affect anything (only may come into play if the system is underpowered)
PSC_ACCZ_I,0.56
PSC_ACCZ_P,0.28 - I realize both of these are too high but it was just to show that is not a “gain issue”
Battery - This is just a test rig, so I haven’t bothered setting these up. I have accurate voltage and current through my radio.

@Leonardthall Is there a hard limit on PILOT_ACCEL_Z? I think the issue here is the Acceleration of the desired Acceleration curve seems to be limited to some value around 300m/s/s/s? This is what is causing the inherent “delay” I am experiencing. Is there anyway to change this value?

8

Your BATT_AMP_PERVLT is wrong and current readings are not good. I mention this just because I’m a firm believer in getting as much as possible right before flying - voltage and current nut you might say :slight_smile: I dont think that will stop it performing properly.

I’d say put in the params listed above in previous posts plus these params below, they’re at least similar to defaults, and do Autotune. Otherwise I’d almost reset all to defaults and start over - unless you’ve got a really low C battery or something there shouldnt be a reason for the craft to be sluggish.

PSC_ACC_XY_FILT,2
PSC_POSZ_P,1
PSC_VELZ_P,2
PSC_ACCZ_P,0.19
PSC_ACCZ_I,0.38
PSC_ACCZ_D,0
PSC_ACCZ_FF,0
PSC_ACCZ_IMAX,800
PSC_ACCZ_FLTT,0
PSC_ACCZ_FLTE,20
PSC_ACCZ_FLTD,0
PSC_POSXY_P,1
PSC_VELXY_P,2
PSC_VELXY_I,1
PSC_VELXY_IMAX,1000
PSC_VELXY_FILT,5
PSC_VELXY_D,0.5
PSC_VELXY_D_FILT,5
PSC_ANGLE_MAX,0
PSC_ACC_XY_FILT,2
PSC_POSZ_P,1
PSC_VELZ_P,2
PSC_ACCZ_P,0.19
PSC_ACCZ_I,0.38
PSC_ACCZ_D,0
PSC_ACCZ_FF,0
PSC_ACCZ_IMAX,800
PSC_ACCZ_FLTT,0
PSC_ACCZ_FLTE,20
PSC_ACCZ_FLTD,0
PSC_POSXY_P,1
PSC_VELXY_P,2
PSC_VELXY_I,1
PSC_VELXY_IMAX,1000
PSC_VELXY_FILT,5
PSC_VELXY_D,0.5
PSC_VELXY_D_FILT,5
PSC_ANGLE_MAX,0
PILOT_SPEED_UP,300
PILOT_SPEED_DN,200
PILOT_ACCEL_Z,300
INS_FAST_SAMPLE,1

9

I totally get it and agree setting those parameters will be important on our non-test aircraft.

I am almost 100% sure this issue has to do with a hardcoded parameter which is “Vertical Jerk” (The acceleration of the desired vertical acceleration). I have looked back at dozens of flights over the last month all which had wildly different gains/parameters and they ALL have a max jerk of roughly 300m/s/s/s.

10

You are getting accelerations up to 6m/s in the log above and you get to your maximum vertical velocity in about 1.5 seconds. The reason PILOT_ACCEL_Z no longer has any impact on the performance is because we limit it to 7.5 m/s/s given that gravity can only pull you down at 9.8 m/s/s. We also Jerk limit the acceleration response so it take 1 second to reach full acceleration.

11

Ahhh this is exactly the “delay” I am feeling. Is there any easy way to change this? With modern ESCs and motors 1.0 sec is very slow and gives a disconnected feeling to throttle response. I would assume a value of around 0.25s would make more sense or better yet, this seems like a parameter I am sure many would like to tune to their propulsion system. On a side note, it does make sense to limit PILOT_ACCEL_Z to around 7.5m/s/s as it would cause descent issues any higher.

12

At this stage it is hard coded however I am currently rewriting the position controller (alt hold in particular) with the rewrite of the navigation controller. So I can keep this in mind as I work my way through the system.

13

Great to hear and thanks for feedback! If you have ever had the chance to fly a DJI A3 controller I think you’ll see what I mean. I’d guess there jerk limit to hit max accel is around 0.1s (complete guess). You combine that with FOC ESC’s and its a night and day altitude control experience.

14

Yeh, they fly like crap. But I understand the “feeling” you are after. The problem is people mistake the sharp response caused by a poor controller design as “responsive” when in reality it is just the controller being unable to keep up with the attitude request. It is like when someone tends to grab the breaks too hard on the car all the time. The breaks provide a good feeling of responsiveness but it doesn’t change the fact the person drives like crap.

I do completly agree that the pilot should be given the ability to tune the aircraft to respond faster and I will keep that in mind as I get to that end of this work! Thanks for your feedback here, it has been useful and will help me moving forward!

15

Good brake pedal example.

Just something to think about when your working on the altitude controller. To get good altitude response it would be useful to have separate Jerk parameters for climb and descend. To get good response the user would have to “tune” these parameters to the users power system. For traditional ESCs that don’t have dynamic motor braking the descend Jerk needs to be much lower than Ascend Jerk to optimize altitude response. From what I understand the Jerk value is a function of the PILOT_ACCEL_Z (takes 1sec to reach max Acc). I think it would make more sense if the Jerk value was simply a set parameter and not a function of PILOT_ACCEL_Z.

This changes once you get into using ESCs with dynamic braking. Then the descend Jerk can be set higher for better response.

Food for thought!

16

Created a short video showing the difference in altitude acceleration/response between the A3 and Arducopter 4.0.3. Both aircraft have very similar power to weight in their current setup.

1 Like
17

If you let me know what flight controller you are running I can send you a firmware with a higher jerk value. It may help me understand what the requirements are moving forward.

Yes, I agree but there is always a support cost to additional parameters. Most people don’t understand what Jerk is, much less take the time to understand how to tune it properly. In the end we spend a bunch of time telling people how they destroyed their tune by setting parameters to stupid values.

My current S-Curve input shaping algorithm takes maximum velocity and acceleration, and a time constant. The time constant is responsiveness and sets the jerk and the approach curve. I won’t go into approach curve here but I have spent a few solid weeks (and I mean 12 hours a day 7 days a week) of unpaid work getting the math to all work correctly. This is not a trivial problem.

So to extend it to both positive and negative jerk is not going to happen both because I can’t aford the time to work though every angle to make sure it is stable in all conditions and the ongoing support effort is not justified by the additional capability.

Any ESC that doesn’t use dynamic breaking should not be on a multirotor aircraft. More importantly than Alt Hold, it is terrible for attitude control. I can accept compromises being made on aircraft over 100 kg but less than that there is no excuse for using unbraked ESC’s. So I don’t consider it a factor here.

1 Like
18

This is what I figured. Just from playing around will all the parameters too much I had an idea of how your S-Curve algorithm worked. I can see how it gets complex.

While I agree dynamic braking ESCs are a game changer, looking through many posts it doesn’t seem like many users have upgraded. That being said, people using braking ESC are bound to have less issues = less posting?

I would really appreciate trying out a modified version. I am currently using a Pixhawk 2.1 Black Cube. My test rigs ESC’s only have a small amount of braking so I think going too crazy with the jerk may have adverse descent effects. I’ll let you make the call but I feel values that would create a jerk of approximately 2.5x may be a good trial. chris@droneunit.com