Tune in auto is very aggressive compared to stabilise

I’m tuning a new quadcopter (X-config) at the moment. This is my first clean sheet build of a multicopter. Some info below…

Motor-Motor centre diameter is approximately 750mm,
Autopilot - Cube Black + Here2
Take off weight = 4.3kg,
Battery = 6S10k LiPo
Motor = T-Motor U5 kV400
ESC = Xrotor 40A
Props = T-Motor polished 15x5
T/W >2
Copter 4.3.6

Here’s the log:
Flight Log

It’s worth mentioning that the aircraft has the weight distributed along the length of the body and tends to be rear biased at the moment - battery offsets the notional payload in the nose which is represented by a weight at present. This means that I can expect some inertia coupling, a softer pitch feel and lower yaw authority when compared to a copter with all the weight centred around the CG.

I set the copter params up using the quick start process in Mission planner. This went well and gave a pretty flyable copter in Stabilise and alt hold.

I have run through all 4 autotune options now - have the least faith in the yaw, the roll is really nice and pitch is pretty good.

Poshold is now fine - first time I used poshold it started to toilet bowl twice and since that point has been fine in poshold.

With these settings I’ve been able to fly 25 or so auto missions up to say 25mph breeze and the drone has performed well. The problem comes when yawing in auto and the drones response in auto - it seems to be hypersensitive and there’s obvious vibration (although the vibration performance is within the limits given in the wiki - in stabilise and althold vibrations are low imo).

Motors don’t get overly hot and are all approximately the same temperature, however they are warm, and the rcout traces are extremely noisy and saturate at the low end as shown below.

This is a section (last 4 segments) of the flight - one auto run around the route, some poshold, and stabilise where I’m flying the aircraft to land.

Servo1-4 out:

Vibrations:

As can be seen, in auto the motors are being worked hard. This problem could be leading to poor yaw authority, and I wanted to get this sorted before working more on the yaw authority in auto mode.

Here’s the extended tuning page from mission planner - please ignore the Harmonic Notch settings - I set those after this flight. The autotune didn’t really do anything with Yaw, so I added those parameters in. I will need to do autotune again on yaw I think. Yaw in stabilise is good.

Any help understanding this situation is appreciated.

@tridge I got a lot of good info from the tuning surgery you posted to the ardupilot channel - if you ever wanted to do another I’d be happy to volunteer this log and tune process to it.

Is this actually a fairly trivial solution?

Loiter is used in Auto for position control. In the extended tuning screen, the following values are highlighted for loiter tuning…

In previous versions of mission planner the frame of P,I,D,IMAX was called ‘Rate Loiter’ instead of ‘Velocity XY(Vel to Accel)’

So, even though the wiki suggests that the P (PSC_VELXY_P) shouldn’t normally need to be changed - should it actually be the larger of the two Rate Roll and Rate Pitch P values? And the same for the I, D and IMAX values?

I’ll check over that log and you can let us know if my advice is the same or different to other advice. That would be appreciated.
Maybe put in the advice you received and it will be instructional.

Or did you mean you were just watching the videos, and didnt receive specific advice for your copter??
I might have misunderstood.


No Battery voltage (or current) monitoring!
You should be able to just enable the battery monitor for analog voltage and current and defaults will work. This makes a big difference to safety and motor thrust scaling. Set these related params

BATT_ARM_VOLT,22.10
BATT_CRT_VOLT,21.00
BATT_LOW_VOLT,21.60
BATT_FS_CRT_ACT,1
BATT_FS_LOW_ACT,2
FENCE_ENABLE,1 // and check other fence settings

Nice low X axis vibrations, but Y axis is higher indicating some mounting issue of the flight controller, wires pulled tight in one direction or something rubbing against the FC.
Z axis vibrations are a bit too high and you should definitely do something about that - there’s numerous causes and fixes.
Investigate and fix this before flying more (but do set all the other parameters I specfiy)

Dont use the Yaw D autotune yet, I think there was a problem, and anyway you probably wouldnt need to go that far. Just use ordinary Yaw autotune when you get back to that stage.

Set these for general fixes

ATC_INPUT_TC,0.2
FFT_ENABLE,0
GPS_GNSS_MODE,5 // or 65
INS_ACCEL_FILTER,10
INS_HNTCH_BW,30
INS_HNTCH_FM_RAT,0.7
INS_HNTCH_FREQ,60
INS_HNTCH_MODE,1
INS_HNTCH_REF,0.3
INS_LOG_BAT_OPT,4
PILOT_THR_BHV,7 // spring-centered throttle

These look a bit high

MOT_SPIN_ARM,0.15
MOT_SPIN_MIN,0.2

Use MissionPlanner motor test to check for the minimum reliable, smooth startup percentage and set that as MOT_SPIN_ARM , then add 0.03 and set the new value in MOT_SPIN_MIN - so you might end up with something like:

MOT_SPIN_ARM,0.10
MOT_SPIN_MIN,0.13

It looks like Autotune produced some skewed results, try these PIDs to settle things down.

ATC_ACCEL_P_MAX,40000
ATC_ACCEL_R_MAX,70000
ATC_ACCEL_Y_MAX,30000
ATC_ANG_PIT_P,8.0
ATC_ANG_RLL_P,10.0
ATC_ANG_YAW_P,6.0
ATC_RAT_PIT_P,0.13
ATC_RAT_PIT_I,0.13
ATC_RAT_PIT_D,0.0065
ATC_RAT_RLL_P,0.12
ATC_RAT_RLL_I,0.12
ATC_RAT_RLL_D,0.006
ATC_RAT_YAW_I,0.06
ATC_RAT_YAW_P,0.6

I advise to set all these params at once - dont pick just a few and do more test flights and expect huge improvements. Work on the vibrations then battery voltage monitoring.
Set all params then test fly using Stabilise then AltHold

Let’s see that log and your summary of the results.

I advise to use Loiter instead of PosHold.

Thanks for your input, I’ll set your profile up in its entirety, weather should be ok to fly tomorrow afternoon so will go fly a back to back.

Battery and current sensing will be solved when I can figure out how to enable the right I2C driver for the Holybro PM03D PDB. I’m happy with endurance based on a time limit until I can get that sorted. Current draw to date has been very consistent. I do want to get that sorted asap.

I will pay some attention to the two wires that could be touching the flight controller.

Z-axis vibrations are interesting. The frame and the layout is somewhat different to the average multi-rotor. I suspect the Z vibes will reduce when whatever is going on in auto is tuned out - as you can see, out of auto they’re significantly lower. There’s no freeplay in either the motors or their mounts and the props are balanced. I was thinking of changing the lightweight tube clamp type tarot mounts plus my spacer adapter, out for the tarot damped mounts. So that’s somewhere to go if needed.

I’ll summarise this entire process in the first post when we’re happy it’s solved. Where the video is concerned there is an ardupilot video where Tridge talks log analysis, covering pertinent points and how to use mav explorer etc and that had helped me to further my own knowledge. There was talk of these sorts of videos continuing, so was offering up this problem-solving situation as something to discuss.

I’ll swap out poshold for loiter.

I strongly advise to get the voltage monitoring working before flying more - technically it’s not mandatory, but in reality we’ve seen so many people with “my copter just fell out of the sky” and “battery wont charge properly” by leaving out the correct voltage monitoring settings and fail safe actions.
There’s also the tuning aspect that is affected by not having the battery voltage available for thrust scaling…

That PM03D is a good idea but I’m not sure how you will get it working with a Cube Black.
You would have to connect those I2C voltage sensor wires to a connector with I2C pins and use the full parameter list to try setting the voltage monitor as per the holybro docs

BATT_MONITOR,21
BATT-I2C-bus,1  // might need to change this
BATT-I2C-addr,65

https://docs.holybro.com/power-module-and-pdb/power-module/power-module-setup

No, stick with the mounts you have. The motor mounts with dampers have proven to make things worse.
The Z axis vibrations could be prop wash over the center plates, over the flight controller or other components, or a whole range of evils.
Or props could be too close to the arms…
Send a photo of the copter and the flight controller mounting of you like.

Yes, all those videos are highly instructive and usually offer clues to other things that might not even be in the videos.

Reporting back…

Setup:

  1. I loaded up all of XFACTAs params that I could load (excludes the power monitoring stuff for the moment - I will work on the PDB problem this weekend).
  2. I re-checked the MOT_SPIN_ARM and 0.14 is the minimum that I can reliably get the motors to all start at. One motor starts at a lower ratio but the other 3 will not activate until 0.14. ESCs and Motors are the same in each position. What variables affect this? I’ve looked at this multiple times with motor testing and Motor 1 (Front Right, CCW) will start at a lower ratio but the rest won’t - and I’ve also changed this motor and all the ESCs in that time with no change in behaviour, so it’s not likely to be a motor issue. Can ESC timing affect this?
  3. I re-calibrated the ESCs using the semi-automated process in the wiki.
  4. I tied back the wires that could have any contact with the cube and its carrier
  5. My telem RFD radio has been on the cover above the cube - I moved that forward, off the cover to remove any chance that it is resonating and transmitting to the fuselage cube area (imagine my design is a quadcopter with a short stubby carbon fibre aircraft fuselage). This will also have shifted the CofG very slightly forward.
  6. Changed PosHold out for Loiter

Logs
Log

Conditions

  1. Same flying field as previous log, Wind was a flat calm, about 16 Celsius.

  2. I saved my params as a profile before modding with the new values. I also saved the profile after adding the new values. I decided I would carry out the following in both the new param set and the old param set.

  3. Translate and rotate about axes in stabilise and althold

  4. Single run of a simple rectangle mission in auto and let the aircraft hover in loiter after end of auto run

  5. althold and Stabilise general flight to land

This is a bit more than asked for, but it’s 30 mins to the field, so thought I’d get more data than requested.

Observations:

  1. In stabilise the aircraft flies in a more ‘relaxed’ manner - roll and pitch are reduced - roll control is about as sharp as pitch control now, whereas before roll control was very sharp. I would like the controls to be harmonised, so this is no bad thing.

  2. Yaw authority was good in all modes - I think the previous params were slightly better at keeping the yaw axis at the aircraft CofG - with these params the yaw centre appears to be away from the aircraft centre of gravity. Importantly, the auto mission had no problem with heading changes at turn points, whereas previously the aircraft could completely run out of overhead for yaw control and end up flying sideways before yawing back to point in the direction of the next turn point.

  3. I had previously had a problem with a ‘chirp’ being emitted by the motors (I couldn’t track down which one it was, but it sounded like a bell housing striking the stator assy), but could never actually track down a reason for it with the physical installation (no play in motors or their mounting). With the new param set, the chirp is gone, and the aircraft seems quieter and smoother. (changing back to the old param set brings the ‘chirp’ back). This appears to be a motor resonance thing?

  4. Loiter could do with tightening up - as can be seen in Auto there is a low period hunt around the desired path and in loiter hover I would say it wanders around 0.75m radius from the desired point.

  5. No change to throttle feel or behaviour - I don’t have a self centring stick for throttle and am used to that - the Tx is used for all kinds of vehicles.

  6. In auto the aircraft is much more relaxed and exhibits the same overall behaviours as in stabilise/althold rather than seemingly having a different tune.

Following are vibe and rcout graphs of a section of the Auto segment

Following are vibe and rcout graphs of a section the althold segment after the auto segment

Again, all help is greatly appreciated. I hope by trying to be thorough in my write-up this will be helpful to others.

Good work with the flights and write-up!
Once you’ve got the voltage readings, Autotune should be able to do a nice job with this.
Any remaining Yaw issues are relatively easy to sort out and can be done last since it’s the least critical axis.

If the motors still get warm, and there is very small oscillations in attitude control, you could try these slightly lower D terms

ATC_RAT_PIT_D,0.00433
ATC_RAT_RLL_D,0.004

or just wait to run Autotune. I dont think it’s a big deal at the moment.

The only remaining annoyance is quite a spread in the motor outputs, which makes for a bit of a mess of frequencies, which in turn makes it a bit harder to set up the Harmonic Notch Filter properly.
IF you had ESC telemetry then you can set a per-motor notch which gets around the problem and would help if you were shifting around payloads and making alterations too.

Weight is currently shifted towards Motor2 and 4, left/rear. If that can be evened out a little more then we would be able to finalise the HNOTCH settings. You might also be able to change over to using the in-flight FFT which would be nice if you are changing payloads.

Hey Shawn, thanks for getting back to me so quickly.

I’ll see what can be done about sorting the CofG. I’ll have a better solution that allows a more central battery position when I don’t have a large fwd payload, in the next fuselage iteration I’m designing now.

Will keep telem capable ESCs in mind.

Will add more info here when I’ve sorted the power monitoring out

I have the Battery Monitor working now.

For those searching - configuring PM03D Power Module with a Cube Black and standard carrier board.

image

I had done this before, but I think I missed the point that every time you change an I2C param, like BATT_I2C_BUS, you must reboot.

On my system, the correct I2C bus is 0.

I have the following params set:

BATT_MONITOR = 21
BATT_I2C_BUS = 0
BATT_I2C_ADDR = 65

I unpinned the SCL and SDA wires from the clickmate connector and also unpinned the SCL and SDA wires from an I2C connector.

For prototyping, the I2C 1.25mm JST-GH pin fits in to the clickmate pin so that the process is reversible while you prove it out.

On the standard cube carrier, I use the ‘I2C 2’ connector. This maps to I2C Bus 0 on my set-up.

BATT_MONITOR = 21 shows up as INA2XX in the mission planner setup/optional hardware/battery monitor tab
I needed to reboot after setting for the BATT_I2C_*** params to become visible.

BATT_I2C_ADDR = 65 is automatically set

BATT_I2C_BUS is auto set to 1 - you need to change this to 0 if using the ‘I2C 2’ connector or to whatever bus you are going to use.

You don’t need to calibrate the monitor, and after setting the above params you will see the sensor entry in the Battery Monitor tab is set to ‘0: Other’.

You don’t need the power and ground cables on the I2C port. I wonder, is it useful to ground the I2C to the PM03D ground?

The power and current pins on the Cube carrier board are for analogue power and current readings.

I’ve now set the other battery related params in XFACTAs first post in this thread.

Good info - thanks for posting a complete set up, this will no doubt help others. Good to know it’s working! Power distribution boards like that are very handy.

Please share the results from an Autotune too - interested to see what happens there.

Yeah, I like the Mauch stuff for larger designs but for what I am working on here, this board is pretty much perfect imo.

So, I’ll autotune one axis at a time but not Yaw D?

I should be able to achieve that tomorrow if the weather holds out.

Yeah - you can certainly Autotune the Yaw axis if you like, but dont use the YawD option yet.
Normally there’s no need to, and i think it’s got variable results at the moment.
Yaw can be done last, and yaw autotune usually gives a low-ish ATC_ACCEL_Y_MAX which can then be increased a bit.

1 Like

Results of around 2 hours of flights today…

Setup:

  1. Made sure I had the correct set of params as I had been switching back and forth yesterday, seeing where the differences were.
  2. Setup controller for autotune - one axis at a time.

Logs:
Circle Mission
Zig Zag Mission

Conditions:

  1. Same flying field as previous flights
  2. Temperature about 17 Celsius
  3. Wind blustery up to 25mph - maybe a bit more at times. Same throughout the session

Observations:

  1. Results of this round of autotune feel ‘nicer’ than the last attempt. The control harmonisation feels better in stabilise and althold mode. Roll feel is more like Pitch feel now.
  2. Good Yaw authority. Now the motors aren’t being thrashed, the Yaw authority definitely feels better
  3. No ‘chirping’ resonance after the tune
  4. Vibrations in Z are high at times - I put this down to dealing with cross wind - up to around 30 degrees lean at times today
  5. I ran a circle mission - my hope here was to have the vehicle fly around the circle tangent rather than point down the radial - is the azimuth option a way to deal with this? Still, this proved to be a useful trial given the wind today. 3 circles in the mission, mission completed twice.
  6. I set up an approx 1km ‘zig-zag’ mission to expand flight time and help me tune Loiter for missions. Spent around an hour running this mission back to back (haven’t found option for it to auto restart mission - I switch in and out of auto on the Tx to restart)
  7. Ext. Tuning Velocity XY P was increased to 1.5 in 3 steps over the course of the zig-zag missions - this tightened up speed control and wander about the desired vector (like damping a dutch roll mode in fixed wing aircraft)
  8. The battery monitor seemed to perform well, its %ages were within a couple of percent of my battery checker. Interesting to see the voltage sag at the beginning of the mission, and then recovery at the end.
  9. Should be noted that the flight in auto now matches flight in other modes - i.e. very much improved.
    10 - almost forgot this negative - I had a red CPU warning on mission planner for almost all flights today - am I in danger of overloading the CPU on the autopilot? What can I do to improve CPU overhead?

New Autotune in Roll, Pitch and Yaw values below:

Circle mode segment from ‘Circle Mission’ log:

Single Circuit:
image



Zig-Zag mission Segment from ‘ZigZag Mission’ log:

Single Circuit



That is good for mid-sized props on a windy day.

Try ATC_ACCEL_Y_MAX about 16000 , autotune seems to give a quite conservative value and it’s very safe to change this up and down somewhat.

I felt like it was working pretty hard at times, so feel good that it’s performing as you might expect. Never felt it was about to go out of control or out of control authority.

I decided that the next prototype is going to go up in tube size as I felt during the yaw autotune today that there was too much flexibility during large yaw inputs.

Good to test in something other than a flat calm and get workable results.

I’ll increase ATC_ACCEL_Y_MAX to 16000.

Doubt I’ll have chance to fly again this coming week, but am off next week so will be hammering the batteries on a few days!

I’d like to understand what was really changed between the params I had at the start of this thread and the params you suggested and autotune has worked with, for my own knowledge, so I can self-start in future.

Here’s a picture of the drone that this tuning was done for…my first unique multi-rotor design.

This is now a retired design for various reasons but mainly because the dynamics of a rear mount battery to enable a nose mount camera system are not good enough.

Currently working up a new, totally modular design which will overall improve on this design.

@rickyg32 has a nice design for Quad X but I dont know if he will be interested in sharing it.
There are some specifics about the design, like the flight controller has been tightly integrated, so a different FC may need quite a bit of rework. A bare FC like a Pixracer suits Ricky’s design.

For tuning a new design, it’s best to get the harmonic notch filter working well as soon as possible, and subsequent tuning will be more effective.
Diligence and attention to detail are key.

  • Mandatory calibrations
  • Voltage and current monitoring
  • Initial Parameters (including failsafe actions!) plus:
INS_ACCEL_FILTER,10
INS_LOG_BAT_MASK,1
INS_LOG_BAT_OPT,4
LOG_BITMASK,180222
  • Harmonic Notch Filter
  • Test flights, adjustments
  • Autotune

Use this spreadsheet for an estimate of HNOTCH FREQ, BW and REF amongst other things. It was the source for the Intial Params in MP, but since updated a bit.

If using a dynamic HNOTCH, like RPM-based, remember to keep the FREQ and BW lower than hover freq and they will scale up with the dynamic input.

EDIT: I’ve just updated that sheet with

  • RPM-based HNOTCH section
  • New MOT_THST_EXPO calculation
  • Old MOT_THST_EXPO is still in the copter 3.6 section for comparison
1 Like

Looking back, I was wondering if you’d posted this in the right thread Shawn?!

No I think we are on track. It is all about tuning after all.

By the way there was a point I missed earlier - where your flight controller CPU was possibly running with high load.
In logs you can look for PM.Load.
If tuning is completed you can reduce some logging with:

INS_LOG_BAT_MASK,0
LOG_BITMASK,176126  //  down from 180222
1 Like