Correct tuning response to manual tuning charts

ArduCopter Copter 4.5
1

I’m working through the process of learning manual PID tuning using the ArduPilot Web-Tool “PID Review” utility. And using BIN charts. The only instruction on the PID Review tool I was able to find was Chris Rosser’s YouTube video on ArduPilot PID tuning. It’s incomplete.

I think it’s important to point out that the only page in the ArduPilot Wiki for manual tuning is for Helicopters. I assume that those instructions about how to set ATC_RAT_xxx_FF, ATC_ACCEL_x_MAX, and ATC_ANG_xxx_P are similar to how to set them on multi-copters. But I have no way to know for sure. Here’s the link to this page: Manual Tuning Instructions — Copter documentation

I’ll present my pitch and roll data separately - but would appreciate comments and suggestions on how to go about improving these results

PITCH

Here’s the BIN plot of actual versus requested pitch:

pitch rate
pitch rate1920×1044 120 KB

Here’s the PID Review plot of pitch time domain:

Time Domain Pitch
Time Domain Pitch1210×506 74.8 KB

And here’s the PID Review plot of the pitch Step Response:

Step Response Pitch
Step Response Pitch1203×512 224 KB

In flight, pitch response properly - although the Step Response chart suggests that P-Gain should be increased.

ROLL

Here’s the BIN plot of actual versus requested roll:

roll rate
roll rate1920×1043 115 KB

Here’s the PID Review plot of roll time domain:

Time Domain Roll
Time Domain Roll1206×511 64.5 KB

And here’s the PID Review plot of the roll Step Response:

Step Response Roll
Step Response Roll1197×504 269 KB

In flight, pitch responds more aggressively than roll - and will roll back and forth very slightly after releasing the sticks when returning to level flight. This behavior has been reduced a great deal as I’ve slowly raised all the roll PID gains.

The charts suggest that the P-Gain for roll should be increased, but as the copter rolls back and forth a slight degree still to settle, I’m wondering if roll P-Gain is already too high.

All the related parameters, ATC_RAT_xxx_FF, ATC_ACCEL_x_MAX, and ATC_ANG_xxx_P are still at their defaults.

I would appreciate suggestions that might guide me through the next test setting and flights.

For what it’s worth - the copter is certainly stable enough to do AutoTune. But I’m trying to get my hands around the manual tuning process.

Thanks!

2

Huh?
There is a whole series of tuning Instructions including Manual Tuning.
Tuning Process Instructions
There is a link to Transmitter Based Tuning in the Manual Tuning of Pitch and Roll section which is the best way to get a good result.

1 Like
3

Can you supply the .bin log file?
I dont think I’ll be able to add anything regarding the PID Review tool, but maybe I can spot something wrong somewhere. To me it looks like there’s lag between desired and actual.

4

I disagree.

The wiki on Tuning Process Instructions tell how to set up a copter that’s stable enough to then use the automation (Quick Tune and Auto Tune) to do the tuning settings.

Even then there are gaps. It says to disable feed forward, but I don’t recall seeing when it says when to re-enable it - or how to set the associated parameters.

The section on Transmitter Based Tuning explains how to modify tuning parameters in flight - but not how and why to set them.

Which brings me to another point. A copter that is visibly stable isn’t necessarily tuned.

I would guess that this one reason that @iampete went to the trouble of creating the PID Review tool - so that a data based tune could be achieved.

If you think about it - tools like Quick Tune and Auto Tune are using data. And that data is recorded. We should be able to use this same data to adjust the tuning parameters ourselves.

The ArduPilot PID Review tool (and Filter Review tool) are designed so that people knowledgeable in process control tuning can do the things they know how to do. Unfortunately, I suspect that the average ArduPilot builder is not skilled in process control tuning. That’s one reason why automated tools such as AutoTune were created.

I’ve entered an issue on the PID Review’s GitHub page regarding the lack of information about how to use these tools. It was Chris Rosser’s YouTube videos that gave me a toehold into how to use these tools. Unfortunately, those tutorials are incomplete. But those tutorials did give me a head start - and I was able to use them to properly set up a notch filter, set PIDs that flyable and don’t oscillate.

No doubt, the missing documentation would be no small project to create. But if it were focused on use, not theory, I think it might be possible. For example - torqueing a cylinder head can be achieved by simply instructing the torque wrench settings to use, and the sequence to tighten the bolts. It does not have include things how a torque wrench actually works.

I like to contribute to documentation efforts - but as I lack the necessary information, I’m unable to do so for setting tune parameters.

I’m hoping that for the benefit of successful use of ArduPilot, an effort can be made to fill this gap. I promise to do my bit to contribute.

1 Like
5

Thanks Shawn - sorry for the delay.

6

Do Not use the heli manual tuning page for multirotors. Different Beast.

Yes but that is a very iterative method. You could do the standard method of increasing D until oscillation, back of gain until it stops, and then increase P until oscillation and back off gain. Then you would have to check it in this tool.

Great! I think manual tuning should be something that is rarely used to optimally tune an aircraft.

So why are you not using Autotune? It sounds like you want to learn how to tune manually which is great but I don’t think there needs to be another wiki. there is already a wiki on manual tuning. For a basic tune, I think this is sufficient.

The arducopter analytic tune tool was created to allow someone to obtain an optimal tune. I realize that it is a little beyond most users because it works in the frequency domain but it gives you the ability to turn the knobs (so to speak) and dial in an optimal tune. There is a video on how to use this tool to obtain a good tune by Leonard.

2 Likes
7

Use these settings. They do quite enough of noise filtering without causing too much lag or interference. The settings you had were actually doing almost nothing at all, post filter noise was almost equal to pre-filter noise.

image
image560×637 41.7 KB

If you suspect the notch filter is still interfering then deselect Multisource. Deselecting it wont hurt anything either so dont be afraid to go without it.
You really only need INS_LOG_BAT_OPT,4 - sensor rate logging is only important if you know what to do with it and you are looking for a specific issue. I’m sure I dont know what to do with it :slight_smile:
I cant recall if it’s required for the PID tool though.

Attitude control is a bit poor, and yaw and altitude is affected unnecessarily by pitch and roll.
I suspect a few PID improvements can be made easily before getting to Autotune or other work.
Let me know if you want my suggestions here - basically higher Angle P’s and slightly higher Rate PID’s.

Considering your goal of using the PID tool to refine PIDs and facilitate manual tuning, one method could be:

  • gather some flight data and screenshots of the PID tool now (including my filter changes of course)
  • run Autotune and gather a new lot of data to put through the PID tool
  • grab the screen shots again and compare
  • Determine what changes Autotune made and what effect did it show in in the PID tool?
  • How did the Autotune result match up to expected performance and attitude control?

I know that’s taking a short cut, but it could give an insight into what to expect and maybe how to get there.
That would be off interest to a lot of us.
I would do that too, but I dont have a small quad I can afford to mess around with at the moment.

Set these before disaster strikes:

BATT_ARM_VOLT,14.70
BATT_CRT_VOLT,14.00
BATT_LOW_VOLT,14.40
BATT_FS_CRT_ACT,1
BATT_FS_LOW_ACT,3 (SmartRTL should be good under the trees)

You could also use these:

GPS_AUTO_CONFIG,2
GPS_GNSS_MODE,7

That tree canopy is going to cause endless issues though. The GPS position and IMU-calculated position is always mismatched.

8

Unless I’m missing something, it seems like there are two links to the trad heli manual process, but in this case you’re recommending it not be used?

9

Joshua, Thanks for catching that. I’ve corrected the link in the original post and have provided it here

1 Like
10

Thank you for your analysis of my BIN file and detailed analysis. Sorry for my late response - I’ve been away for a few days.

Here are some thoughts/responses to your comments:

  1. I had noticed that the Notch Filter was doing very little. I explored a few ideas about this and then noticed that the vibration level on this quad is very very low. (especially on IMU0 and IMU1) I suspected that may have been the reason that the Filter Review Tool showed so little notch filter attenuation. You can see the low vibration level on the Amplitude vs Frequency chart on the Filter Review tool - and the VIBE levels in the BIN file.

Also - there’s something weird about the Filter Review Tool. If you load my BIN file but then add the check for displaying “Estimated Post Filter” - it shows the sort of filtering one might expect. And it does this without adding or changing the filter settings. So I’m wondering if there is a bug in the Filter Review Tool web site.

Here’s what it shows - with no changes to the filter settings - but including the “Estimated Post Filter” plot:

image
image814×836 91.4 KB

Regarding your proposed settings - I don’t know how you came up with them - perhaps you can explain. My understanding is that with a hover RPM of 5000, a notch filter frequency of 84 is correct. Maybe your results reflected that you simply included the “Estimated Post Filter” plot.

  1. Thanks for the tip about INS_LOG_BAT_OPT,4. I’m not sure how I came to include the sensor rate logging - but I’m happy to remove it and have slightly smaller BIN files. If you ever find out how to use sensor rate logging - I’d love to learn about it.

  2. My objective in this exercise is to achieve a good tune entirely manually. In other words - the way it was done before Autotune was created. I have several reasons for this goal - I’m happy to explain offline if you wish.

You mention adjusting Angle P values to a slightly higher value. This is one of the several tune related settings that I can find no guidance for adjusting. And this is the point of this exercise - I’m trying to find out how to set all the tune related parameters from the data in the BIN file.

The comment on this thread by @bnsgeyer mentions a web tool I’d never heard of - the ArduCopter Analytic Tune Tool. This looks like it belongs to the suite of Ardupilot webtools - but it’s not mentioned on GitHub. I’m going to investigate it - but with it’s requirement to set a “chirp” it appears to take some effort to implement.

  1. Good catch on the battery settings - I have no idea how they got zeroed out.

Regarding my test flying under my backyard trees - I haven’t found them to be an issue doing hover tests in Loiter. If there’s something I’m missing, I can easily switch to ALT-HOLD mode instead. And I always choose “land” for my failsafe for this testing - I wouldn’t want my copter to climb into the trees on an RTL. (ask me how I know…)

  1. Regarding your GPS setting suggestions - noted - thanks.

Thanks once again for investing so much of your valuable time on my behalf. I appreciate it.

11

The frequency must be set lower what you would expect at hover (estimate your lowest usable frequency), since the notch filter will never go below this frequency. Similarly the bandwidth should be set proportionally narrow.
That is all because the RPM (from ESC data) will scale your values UP to the correct frequency as required, along with the bandwidth to suit too.
That’s my understanding and the way I’ve always used the ESC/RPM-based notch filter.

1 Like
12

Thank you Shawn - your advice on setting INS_HNTCH_FREQ made all the difference.

I went back and re-read the wiki about setting this parameter - and it’s consistent with your advice - but the language in the wiki probably ought to be improved.

Following your advice, I achieved this result with the notch filter:

image
image806×836 85.3 KB

This in turn allowed the PID’s to behave properly - making it possible to use the PID Review Tool to set the PID’s properly. I did about 10 test flights yesterday making minor changes to both pitch and roll and achieved results that are satisfactory.

The only parameter I’m a little unclear about is INS_HNTCH_ATT. You suggested a lower value than I’m familiar with. Can you please explain how you dirived that value - “30”.

Now having crossed this milestone, I’ll be looking on figuring out how to manually determine the other tuning parameters.

Many Thanks!

13

INS_HNTCH_ATT is the attenuation of the notch in decibels, how sharply it will punch down the noise. With a “MultiSource” notch, this value is “Per Notch”, so you will have N notches where N is the number of sources you have, usually ESCs.

When using MultiSource, it is good practice to reduce the Attenuation and Bandwidth, since in reality the noise you want to filter is an aggregate of all motors. If you yaw and half go high and half go low, you have two peaks and need 1/2 the filtering on each (roughly). You don’t necessarily want the notch settings that would track the aggregate peak to be in effect N times greater.