Simulate motor noise in the gyros and accels

[andyp1per]

This PR enables the simulation of motor-based noise for multicopters. Noise is created at the motor rotational frequency for each motor and combined. The rotational frequency is estimated from the thrust.

The benefit of this simulation is that it allows filtering targeting motor peaks to be tested in SITL. The support includes a test for the notch filter including dynamic FFT analysis using the batch sampler.

The simulation is controlled by setting
SIM_VIB_MOT_MAX to the maximum frequency expected from the motors at maximum throttle. The amount of noise added is controlled by the regular SIM_GYR_RND and SIM_ACCEL_RND settings.

[andyp1per]

@peterbarker I would be grateful for a review!

[tridge]

I'm happy with the SITL C++ changes, just needs peters review on autotest changes

[peterbarker]

On Tue, 3 Dec 2019, Andy Piper wrote: + vibe_log = self.buildlogs_path("ArduCopter-vibration-log.bin") I tried current_onboard_log_filepath() but it fails, just going to stick with the current approach

That's fine. What was the failure, 'though?

[peterbarker]

I'm good with the SITL changes.

[andyp1per]

On Tue, 3 Dec 2019, Andy Piper wrote: + vibe_log = self.buildlogs_path("ArduCopter-vibration-log.bin") I tried current_onboard_log_filepath() but it fails, just going to stick with the current approach
That's fine. What was the failure, 'though?

Something about index out of range

[andyp1per]

Thanks for the logging fix @peterbarker - works well!

[andyp1per]

@peterbarker any idea why I would get this:

   self.check_rc_defaults()

  File "/home/travis/build/ArduPilot/ardupilot/Tools/autotest/common.py", line 967, in check_rc_defaults

    raise NotAchievedException("No RC_CHANNELS messages?!")

NotAchievedException: No RC_CHANNELS messages?!

[andyp1per]

Ok I have rebased and made some tweaks and is passing now. Once the final change gets blessed by CI I will drop the matek commit and it will be ready for merge.

[andyp1per]

@peterbarker I got this failure again:
https://travis-ci.org/ArduPilot/ardupilot/jobs/621076962?utm_medium=notification&utm_source=github_status
I feel like this is a symptom of some deeper problem to do with log downloading. Any ideas? Would cleaning up the logs as we go along make the tests run faster?

[andyp1per]

@peterbarker so I just watched this test in progress, there are basically three problems:

• There's only 2min30s left for the test as it comes at the end of a 47min test run and the timeout is 50min - I think we should increase this
• It generates a 17Mb log file per run which takes 40s to download each time (there are two passes to the test so 1min20s) - some of this is just going to be because of the batch logging, but I wonder whether we are getting a lot of logging from either side of the test that could be removed. Is there a faster way to get the log?
• The EKF takes forever to settle - is there a way to avoid this or speed this up?

[peterbarker]

@peterbarker so I just watched this test in progress, there are basically three problems:

* There's only 2min30s left for the test as it comes at the end of a 47min test run and the timeout is 50min - I think we should increase this

Yep, it's close! Is it actually running overtime?

* It generates a 17Mb log file per run which takes 40s to download each time (there are two passes to the test so 1min20s) - some of this is just going to be because of the batch logging, but I wonder whether we are getting a lot of logging from either side of the test that could be removed. Is there a faster way to get the log?

Rebooting the vehicle (which you are doing) must start a new log, so it's almost certainly All Your Fault :-P

I did suggest the faster way to get the log - reference it directly using dfreader_for_current_onboard_log. That didn't work straight-up - I really only added that to solve my particular need at the time and didn't extensively test it. Perhaps if you give me instructions on how to reproduce the index-out-of-range bug I could fix that?

* The EKF takes forever to settle - is there a way to avoid this or speed this up?

I've been wondering about pushing stream rates way-down and pushing sim-speedup way-up for periods where we don't really care about anything but simple things like this. Long traverals to waypoints (like the quadplane tests) might also be candidates for this.

But generally, no - there are hard-wired timeouts in the EKF which makes shortening settle-time problematic.

[andyp1per]

Ok I have disabled LOG_DISARMED and that has produced a mcuh smaller log that can be downloaded in 5s. Still timing out though ...

[andyp1per]

@peterbarker I got the test working with dfreader_for_current_onboard_log() thanks! Observing the test its slow because of EKF because of GPS fix - is there any way to speed up the GPS fix? I don't remember it being this bad.

[peterbarker]

@andyp1per One option might be setting EKF type 10. I'm really not sure, 'though.

[andyp1per]

@peterbarker tests are now clean - good enough? 🙂
SITL copter is 47mins30s, so I don't think I have added to the overhead much now.

fixed issues