Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MC gyro cutoffs - Reduce IMU_GYRO_CUTOFF to 30Hz and disable MC_DTERM_CUTOFF #11950

Merged
merged 1 commit into from May 7, 2019

Conversation

bresch
Copy link
Member

@bresch bresch commented May 3, 2019

IMY_GYRO_CUTOFF decreased to 20Hz 30Hz

A lot of people realized that their drone is more sensitive to noise since the last release - possibly due to the increased default cutoff frequency of the gyroscope. A low gyro cutoff is needed for most medium/large size drones as the structural natural and blade-pass frequencies are low and people are flying more and more large powerful drones.

  • A higher value is still desirable for small platforms such as racers or well isolated autopilots and should be tuned by the user.
  • Specific values for config files are untouched.

MC_DTERM_CUTOFF deactivated by default

The cutoff filter for the D term is disabled here as the required cutoff frequency for the default D term of the rate controller is higher than the gyro cutoff. In that case, enabling the D term cutoff would just add some undesired phase lag to the derivative.

Proof:
A common rule of thumb used in the industry is to set the D term filter cutoff frequency equal to one tenth of the derivative time constant (ref: controlguru.com (bottom of the page)):

The time constant of a 2nd order with a cutoff frequency of is given by:

Since the time constant of the derivative part of the controller is

We can express the desired filter cutoff as a function of the P and D gains:

Since the default gains of PX4 are:
MC_ROLLRATE_P = 0.15
MC_ROLLRATE_D = 0.003
The desired cutoff frequency would be

and is smaller than the gyro cutoff frequency of 20Hz 30Hz.

FYI @LorenzMeier

We will test it on a few vehicles ASAP

@bresch bresch added this to the Release v1.9.0 milestone May 3, 2019
@bresch bresch requested review from bkueng and MaEtUgR May 3, 2019 08:49
@bresch
Copy link
Member Author

bresch commented May 3, 2019

Test at 30Hz on a S500, default gains (except rate integrator a bit higher):
https://logs.px4.io/plot_app?log=6ba405c2-f24f-426f-a592-bd29a12abfee
Test at 20Hz, same setup:
https://logs.px4.io/plot_app?log=92d53091-efa4-4cb8-8335-99ba8faa8757

At 20Hz I started to feel the delay on that vehicle with default gains, at 30Hz the feeling was quite good. I will increase the default to 30Hz in that PR and test on other vehicles.

@dagar
Copy link
Member

dagar commented May 4, 2019

This is already a very common change to make on typical hobby quality setups, so I'm in favor of changing the default for v1.9.0.

The problem is the good setups where this default was appropriate are now going to get worse after an upgrade. In this case all we can really do is call attention to the change in the migration guide section of the release notes.

@LorenzMeier LorenzMeier added this to To Do in Release 1.11 Blockers via automation May 4, 2019
@LorenzMeier LorenzMeier marked this pull request as ready for review May 4, 2019 14:44
@bys1123
Copy link
Contributor

bys1123 commented May 4, 2019

As most people who use drones are professionals, default parameters is most for beginners who uses F450 S500. Lots of PX4 users are in university, they good at algorithms but not quite good on making drones, they also do not have much time for adjust the parameters. I think maybe add a frame preference for large drones instead of change defaults is better, make students and testers can have an extremely flight at beginning, will also make them dig deeper.

@LorenzMeier
Copy link
Member

The S500 needs 30 Hz - that is the whole point why changing the default makes sense.

@bys1123
Copy link
Contributor

bys1123 commented May 5, 2019

https://twitter.com/bys_1123/status/1124762888147619840
FYI, I tested at April it feels extremely stable, (need a little lower P to 0.125/0.135)

@bresch
Copy link
Member Author

bresch commented May 6, 2019

@PX4/testflights Can you test that PR on all you multicopters please?

Make sure to have:

  • MC_DTERM_CUTOFF = 0
  • IMU_GYRO_CUTOFF = 30
    And the attitude/rate gains at default values (from the config file).

@bresch
Copy link
Member Author

bresch commented May 6, 2019

@bys1123 Thanks for the feedback and the video.

This PR is not just about the S500 and I understand and see that you vehicle flies properly with the current cutoff value. However, I can see in the video that you have an isolation mount under the autopilot, which certainly reduce the amount of vibrations transferred to the autopilot and makes the job of the digital filter; not everyone has that and we should make sure that even the drones with hard-mounted autopilots can fly with default values.

This default value is also something needed for larger vehicles (e.g.: >15kg drones) that have low RPM rotors with a blade-pass frequency that can go down to 50Hz. Natural resonance modes of a frame are also often located in the 30-80Hz range on those vehicles and we should make sure that the sensitivity is low is that region.

For you application, simply set the desired D-term cutoff and gyro cutoff in your dedicated config file or manually in you vehicle via QGC and you won't notice any difference. I still encourage users to tune the filters for their application as it can 1. improve attitude/rate tracking and 2. increase stability margins.

Check the user guide for more details on how to tune the low-pass filters of the rate controller.

Copy link
Member

@bkueng bkueng left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm ok with the change, however we have to be aware that we mostly hear about the cases where the defaults don't work.
Having per-vehicle-class defaults would probably make sense.

@@ -538,6 +538,8 @@ PARAM_DEFINE_FLOAT(MC_TPA_RATE_D, 0.0f);
* The D-term uses the derivative of the rate and thus is the most susceptible to noise.
* Therefore, using a D-term filter allows to decrease the driver-level filtering, which
* leads to reduced control latency and permits to increase the P gains.
* A good rule of thumb is to fix the time constant of this filter equal to one tenth of the
* derivative time constant: MC_DTERM_CUTOFF = 10 * MC_(ROLL|PITCH)RATE_P / (2 * pi * MC_(ROLL|PITCH)RATE_D)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This formula gives too high values for the setups I looked at (about 130). Also, setting this properly depends on the vibration frequencies, which are not in the formula, so I don't think it's very helpful advice.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This rule means "If you choose that cutoff, you are sure that the filter will not add too much phase lag". I checked and in the config files we have more
MC_DTERM_CUTOFF ~= 5 * MC_(ROLL|PITCH)RATE_P / (2 * pi * MC_(ROLL|PITCH)RATE_D)
Maybe having that factor 5 is better for our setups given the amount of noise.
Should we remove completely the rule of thumb of the parameter description and add it to the documentation when we have more tests on that equation?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it means something different, why didn't you write that then? :)
Yes it sounds like it should be in the documentation, and more in detail as to what it means. And since we're lower by a factor of 2, and it still works fine, the formula doesn't seem to be a strict bound, so I question a bit its usefulness.

@bys1123
Copy link
Contributor

bys1123 commented May 6, 2019

@bresch Really thanks for your information. I'll transfer this info to Chinese community too.

dagar
dagar previously approved these changes May 6, 2019
@Tony3dr Tony3dr added this to Ready for testing in Test Flights May 6, 2019
@jorge789
Copy link

jorge789 commented May 6, 2019

Tested on PixRacer V4:

He made sure to have:

MC_DTERM_CUTOFF = 0
IMU_GYRO_CUTOFF = 30

  • Modes Tested
    Position Mode: Good.
    Altitude Mode: Good.
    Stabilized Mode: Good.
    Mission Plan Mode (Automated): Good.

Pre-flight Procedure:

Flash firmware through QGC ✓
Arm vehicle ✓
Calibrations ✓
Parameter check ✓

Flight Test:
Arm and Take off in position mode ✓
Throttle Test ✓
Pitch, Roll, Yaw ✓
Mode Switch ✓
RTL ✓

  • Procedure
    Arm and Take off in position mode, after flying for approximately one minute, switched to altitude then stabilized mode proceed to switch to mission plan mode then make sure that vehicle follows all waypoints as shown in QGC, once completed all waypoin activate RTL and see landing behaviour.
  • Notes

No issues noted, good flight in general.

Flight log: 1

https://review.px4.io/plot_app?log=4278e8c1-fe6b-4ff9-a99f-e8eaede0c9bb

Flight log: 2

https://review.px4.io/plot_app?log=ca75be8c-45d4-4982-af4e-91deddc77fcb

Flight log:Comparison to master.

https://review.px4.io/plot_app?log=35de3fc0-fa47-4cc4-8558-109761e6fba4

Tested on Pixhawk 2 Cube V3:

He made sure to have:

MC_DTERM_CUTOFF = 0
IMU_GYRO_CUTOFF = 30

  • Modes Tested
    Position Mode: Good.
    Altitude Mode: Good.
    Stabilized Mode: Good.
    Mission Plan Mode (Automated): Good.

Pre-flight Procedure:

Flash firmware through QGC ✓
Arm vehicle ✓
Calibrations ✓
Parameter check ✓

Flight Test:
Arm and Take off in position mode ✓
Throttle Test ✓
Pitch, Roll, Yaw ✓
Mode Switch ✓
RTL ✓

  • Procedure
    Arm and Take off in position mode, after flying for approximately one minute, switched to altitude then stabilized mode proceed to switch to mission plan mode then make sure that vehicle follows all waypoints as shown in QGC, once completed all waypoin activate RTL and see landing behaviour.
  • Notes

No issues noted, good flight in general.

Flight log: 1

https://review.px4.io/plot_app?log=be819c09-6175-45e1-a771-52e134e03325

Flight log: 2

https://review.px4.io/plot_app?log=06dbdf93-78d3-4b7b-96fd-3347f99b8e7f

Flight log:Comparison to master.

https://review.px4.io/plot_app?log=24027025-b9cd-4f23-97ed-67b1ec94061f

@dannyfpv
Copy link

dannyfpv commented May 6, 2019

Pixhawk4 v5
Modes Tested
Position Mode: no issues
Altitude Mode: no issues
stabilized Mode: no issues
mission Plan Mode (Automated): no issues
re-flight Procedure:

Flash firmware through QGC ✓
Arm vehicle ✓
Calibrations ✓
Parameter check ✓

Flight Test:
Arm and Take off in position mode ✓
Throttle Test ✓
Pitch, Roll, Yaw ✓
Mode Switch ✓
RTL ✓

Procedure
Arm and Take off in position mode, after flying for approximately one minute, switched to altitude then stabilized mode proceeds to switch to mission plan mode then make sure that vehicle follows all waypoints as shown in QGC, once completed all waypoints activate RTL and see landing behavior.
Notes
No issues noted good flight in general.

logs: https://review.px4.io/plot_app?log=adac11f7-9500-4220-aba1-6a8a45288a6e
https://review.px4.io/plot_app?log=5cec3033-d04a-4e47-baf3-e91f4c049a44

master: https://review.px4.io/plot_app?log=04032970-bb7e-4aed-9f42-e9cdb1273029

@Junkim3DR
Copy link

Tested on Pixhawk 4mini v5

Preflight Checks:

  • MC_DTERM_CUTOFF = 0
  • IMU_GYRO_CUTOFF = 30

Modes Tested

  • Position Mode: Good.
  • Altitude Mode: Good.
  • Stabilized Mode: Good.
  • Mission Plan Mode (Automated): Good.
  • Failsafe RTL (RC Loss): Good.

Procedure
Arm and Take off in position mode, after flying for approximately one minute, switched to altitude then stabilized mode proceed to switch to mission plan mode then make sure that vehicle follows all waypoints as shown in QGC, once completed all waypoint turn off RC to trigger Failsafe RTL and see landing behaviour.

Notes
No issues noted, good flight in general.

Logs:
PR 11950

Tested on Pixhawk Pro v4

Preflight Checks:

  • MC_DTERM_CUTOFF = 0
  • IMU_GYRO_CUTOFF = 30

Modes Tested

  • Position Mode: Good.
  • Altitude Mode: Good.
  • Stabilized Mode: Good.
  • Mission Plan Mode (Automated): Good.
  • Failsafe RTL (RC Loss): Good.

Procedure
Arm and Take off in position mode, after flying for approximately one minute, switched to altitude then stabilized mode proceed to switch to mission plan mode then make sure that vehicle follows all waypoints as shown in QGC, once completed all waypoint turn off RC to trigger Failsafe RTL and see landing behaviour.

Notes
No issues noted, good flight in general.

Logs:
PR 11950

@bresch
Copy link
Member Author

bresch commented May 7, 2019

@jorge789 @dannyfpv @Junkim3DR Thank you guys!
@bkueng I'll update the comment of the parameter and we can merge

MaEtUgR
MaEtUgR previously approved these changes May 7, 2019
Copy link
Member

@MaEtUgR MaEtUgR left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's see if that helps with the reported osciallations. I would also take the rule of thumb out. There are too many influencing factors, it's probably better to just leave it untouched if you're not really tuning. We can give some real world examples as reference in the documentation.

…_CUTOFF.

A low gyro cutoff is needed for most medium/large size drones as the structural natural and blade-pass frequencies are low.
A higher value is still desirable for small platforms surch as racers
or well isolated autopilots and should be tuned by the user.
Specific values for config files are untouched.
The cutoff filter for the D term is disabled here as the required
cutoff frequency for the default D term of the rate controller is higher
than the gyro cutoff. In that case, enabling the D term cutoff would
just add some undesired phase lag to the derivative.
@bresch
Copy link
Member Author

bresch commented May 7, 2019

@bkueng I removed the comment, please approve again

@bresch bresch merged commit 6d8d8e3 into master May 7, 2019
Release 1.11 Blockers automation moved this from To Do to Done May 7, 2019
Test Flights automation moved this from Ready for testing to Done May 7, 2019
@bresch bresch deleted the pr-mc-cutoff branch May 7, 2019 10:15
@CarlOlsson CarlOlsson changed the title MC gyro cutoffs - Reduce IMU_GYRO_CUTOFF to 20Hz and disable MC_DTERM_CUTOFF MC gyro cutoffs - Reduce IMU_GYRO_CUTOFF to 30Hz and disable MC_DTERM_CUTOFF May 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

None yet

9 participants