How to Tune Copters with Seriously Heavy Payloads

Hello All,

I am starting to fine-tune a large hexacopter with 15 Kg payload capacity for spraying. I have previously worked on small multi-rotors and done Autotune multiple times, but never tried to tune a copter that carries such a significant payload, which is actually reducing in weight over the course of flight. So in need of expert guidance from the community.

The hardware/software setup is as follows:

HobbyWing X8 Pro Power Combo (100 KV Motor, 30x90 Prop)
12S 22000mAH Battery
Take-Off Weight No Payload: 20.5Kg
Pixhawk Cube Black
Arducopter 4.0.0

I started following the Tuning Instructions and set all the parameters as explained in this guide. After a couple of successful flights I was confident to try Auto-tune. I have completed Autotune on all three axis. As the guide suggested, Autotune was done in Most agile configuration with Fully charged battery and No Payload.

Here are the logs from a Manual Flight and Auto Mission after the Autotune. Both flights were done without any payload. Please comment on the current state of the tuning and suggest any improvements that can be worked on.

Now, i want to add 15kg payload (maybe in smaller steps of +5kg) and start spraying. As per the tuning instructions referred above, here is what it suggests to do for large payloads:

@Leonardthall Is this the only change required to safely fly with added payload after tuning the copter without any payload? What about the PID gains, is there any need to re-adjust the PID gains or maybe even run the auto-tune again? How does arducopter manages to control a copter where the weight is constantly decreasing (From 38 Kg Fully loaded at Take-off to 22 Kg at Landing)?

Anyone with experience of tuning a similar setup please share your experience and findings on how to correctly tune such a system.

Thanks for the support as always.


Yes this is the way.
Always tune for the most agile (least weight) and that is it.
Tuned many dusters and heavy lifters in the 20-50Kg range. Never had a problem.

Your log looks good, not perfect but good. There are still some undershoots for pitch/roll. Try another autotune in dead calm weather…

1 Like

Thanks @Eosbandi for the quick feedback :slight_smile:

I did the Autotune with AUTOTUNE_AGGR set to 0.1. Should i change that to a lower value for the next autotune?

If not experiencing overshoots or oscillations then .1 is fine.


Yes this is correct. The PID values will cover the full weight envelope if you set it up as discribed above and your auto tunes are working properly.

On my Callisto aircraft I can drop a 25kg payload and the aircraft doesn’t blink. I can attach it hard mounted or slung with no problems provided the position controller does not interact with the time constant of a slung playload.

The only thing you need to be mindful of is slosh in the tank. However I don’t expect this to be a problem.

1 Like

Thank you @Leonardthall. I am about to test first hover with 5 Kg and will move in steps of 5 to full capacity of 15 Kgs if everything goes well. Will share the logs for your expert analysis.

I have another quick question regarding hover throttle (MOT_THST_HOVER). I used MOT_HOVER_LEARN before the autotune and it converged to a value of 0.185. I have set the following: image
From my limited understanding, there should not be a need to learn hover throttle with full payload as the weight of aircraft will keep reducing and come down to empty weight before landing (or reduce instantly in case of drop payload). Please correct me if this is not the case.

Thanks again

Hello Everyone,
Before moving to flight testing with payload, i looked through the logs specifically the Altitude Hold performance. I need your comments and input on the analysis below.

Here are my observations:

  1. In Auto Mission, copter is losing some altitude at each corner as seen in the screenshot below:
  2. In manual flight, Copter loses altitude at the end of each Roll/Pitch Input. More than one meter when looking live at the copter. Screenshot below:

The copter is given a very gentle Roll/Pitch input for a short time in above graph and i am not sure if the altitude change can be attributed to pressure difference created after a fast forward movement. Furthermore, The copter has a properly sealed canopy and advertised by manufacturer for all weather operation. The barometer is showing large altitude changes after every stick input, and these could be seen very clearly when flying the aircraft.

What steps should be taken to tune the altitude controller to have a better hold?

I have done a flight with hover only to check the altitude controller behaviour in Position Hold. And the Altitude stayed fairly constant for the whole 10+ mins of the flight.

Any thoughts?

I am still thinking about what is the best way to handle these situations and what is the best setting to use. At the moment I am thinking that a well tuned aircraft should probably set hover throttle based on the maximum payload. However this has dangers for aircraft that are not tuned correctly if they start to oscillate.

First you need to establish that you need better altitude hold. You need to compare your DAlt with your Alt. This is the data that is being used to control the altitude. In your case you are seeing a drop in 0.4m in your corner. Your baro altitude varies much more because of the changes in pressure as your aircraft changes attitude at speed.

Hello All,

Found calm weather this morning and did a flight with 15L of water in the tank. AUW was at 36 Kg.
Changed the following parameters to accommodate 36 Kg weight:

Here is the LOG file for this flight.

Took off in STABILIZE mode and later switched to ALT_HOLD. The aircraft held its altitude well with no stick input on Roll/Pitch.

Switched to POS_HOLD and aircraft was able to hold its position fairly well.

Key Observations:

  1. When applying only a Left ROLL input in POS_HOLD i did notice the vehicle leaning forward as well (as if there was a pitch input) and not moving perfectly along the ROLL axis only.
  2. Aircraft did loose significant altitude when ending a Roll/Pitch movement. Will make a video & share
  3. The voltage sag was around 2.0 volts. I am using a MAUCH PL 200A HV Sensor along with MAUCH PL 4-14S Hybrid BEC (2x 5.3V & 1x 12V output).

@Eosbandi Can you please review the Log file and comment on the performance of Position Hold? Do you think aircraft is ready for an Auto Mission. Any suggestions on improving the altitude hold when ending a Roll/Pitch movement would be awesome.

Dear @Leonardthall

I did plot the DAlt, Alt (From CTUN) & Barometric altitude (From BARO) against the RCIN (Roll, Pitch & Throttle) to see the altitude controller behaviour. To my surprise, the delta between Alt & DAlt after each movement is much less (in the range of 0.4m ) compared to what i witnessed in the flight. The max speed of the vehicle was less than 3.5 m/s.

I will try to capture that in video on the next flight.

Is there a possible scenario where Copter is actually losing more altitude (more than 1 m) but the FC is seeing a relatively small change?

Looking forward to learning more on the possible causes of this issue.


I would suggest you use Loiter rather than Pos Hold. Loiter is a much more elegant mode than Pos Hold. Pos Hold switches back and forth between Alt Hold and Loiter depending on where your sticks are. Loiter is completly consistent and if Loiter is working well then you can be confident that all Auto modes are working well.

Yes, the point is the altitude controller is not looking at CTUN.BAlt or BARO.Alt, it is looking at the output of the EKF shown in CTUN.Alt. The trick is knowing what your height variation actually is. If you are looking at your log and thinking that your Baro altitude is correct you may think you have much worse performance than you actually are. It is hard to get a good measure of what is actually happening. Lidar height data is good over a flat field for example. It gives you confidence you know exactly what is happening to the aircraft. Video is also helpful.

If you are getting worse than 0.4m then the question is why is the EKF under predicting the height variation and Alt_Hold PID tuning can’t do anything.

Hi @Leonardthall

Alright, so i will do my next flight in LOITER instead of POS_HOLD. I have a question related to LOITER parameters off-topic but better to ask :slight_smile:

  1. Does LOITER parameters E.g LOIT_BRK_ACCEL applies to all Autonomous modes like Guided Mode?
  2. If not, then what is the parameter to control braking acceleration in Guided and other Auto Modes.

I will make a video of next flight for more precise analysis of how much altitude is lost during these manoeuvres. I do have a TF-02 LIDAR and would work on integrating it for more accurate altitude measurements.

Many Thanks

1 Like

Loiter is an approximation of Alt_Hold on a perfectly calm day with the addition of extra breaking when you let go of the sticks. All LOIT_XXX parameters define that “pilot experience”. As such these parameters are not used in any other mode.

Guided is generally attempts to follow the command perfectly. When you put waypoint or “go to here” style commands you are issuing a WP_Nav command and your parameters for breaking and acceleration will be based on the WP_XXX parameters.

This is a very layered problem:
Frame - Power system, Flex, vibration, alignment, cg
Sensor - accuracy, precision, drift
Attitude control
Position control
Then Loiter, WP_Nav and Guided

I guess Pilot is in there somehow too…

Part of the trick to looking at this problems is working out at which layer the problem is happening.

A lidar is pretty critical for very accurate althold in my experience. Which GPS module are you using?

Hi @vosair

Its a Here2 GPS Module configured as I2C. Flight controller is Cube Black.

I am working on integrating the TF-02 LIDAR at the moment. I do hope it improves the altitude hold performance. It is critical to have precise altitude control as this is a spraying drone flying at 5m altitude only.

Any reason you’re running the Here2 via I2C and not CAN?

I don’t have experience with the TF-02, but I’ve used the TFmini for front avoidance. I’ve used the LeddarOne and LW20 for downward facing lidar and they both work well. I wonder if the lidar will see spray droplets and get confused?

Have you thought about using a terrain model instead of lidar? The downside is you would have to fly the area once with GCPs to get an accurate terrain model.

Import the model into mission planner, plan your mission and check terrain. I works very well and is quite accurate.

Hi @vosair

I got this Here2 Unit way back when things were not settled on CAN side. Haven’t taken the pain to disassemble again and switch it back to CAN & swap the cable. I can surely switch to CAN if there is some performance related improvement (higher up-date rate etc) that i am missing on. Haven’t read much on the benefits of CAN honestly, so maybe you can give some motivation :slight_smile:

Well, that needs to be seen. I will surely update one this after trying it out.

Hello David,

The issue i am working on currently is to have a good altitude hold while manoeuvring. As i understand, having an accurate terrain model is very helpful in flying a constant altitude above terrain in AUTO missions but for it to work properly, i must have the altitude controller working at its best with whatever sensor i have for altitude measurement. That is why i am considering the LIDAR to provide the altitude controller with accurate altitude.

Once that is done, i plan to move to terrain following using LIDAR. The extra overhead of first building an accurate terrain model can be justified for one or a set of fields that I want to fly on a regular basis but is tedious to do for on the fly requests etc.

Thank you for the input. Cheers

Hi @Leonardthall

Thank you for the clarification.

WPNAV_ Parameters only have WPNAV_ACCEL and not a separate parameter for braking (deceleration like LOIT_BRK_ACCEL). Does this mean that WPNAV_ACCEL is also used for decelerating when reaching a waypoint?

Many Thanks