First flight OK, have tuning question

ArduCopter Copter 3.6
1

I did the first test flights of my new drone yesterday. No problems. Docile behaviour, a bit sluggish perhaps, with the default tuning parameters. But I have questions after analysing the logs and parameters, before proceeding to autotuning.

Setup: Clone F450 frame, 2212 KV 930 motors, 10x4.5 props, clone Pixhawk 2.4.8, Arducopter 3.6.8, Littlebee Spring ESCs with BLHeli_S, running in Oneshot, 3S 5Ah battery, 1155 grams total takeoff weight.

I set up the parameters as recommended in the docs, and made every test I could on the ground. Then went outside, tied a 10m long leash to the drone, tied the other end to a brick,armed in loiter mode to make sure the GPS is working, switched to stab mode and took off, landed right away. No strange behavior. Then took off again, brought the drone to 5m height, did a little further testing with little tilts in all directions, all seemed fine but the drone tends to go up and down, probably due to self-created turbulence. Switched into althold mode, that worked fine, no longer needed to ride the throttle. Landed in althold mode, took off again in althold, went to 5m height, engaged loiter mode. Fine too. Made some motions in all directions, even full stick ones, the attitude response seems quite clean and direct, the position holding is a bit sluggish, with overshoot. One cannot go very far when tied to a 10m long leash with a brick at the end, so I landed after 5 minutes total flight time for all three test flights, downloaded the logs and parameters, and now Iā€™m studying them.

Autoanalysis reports the following:

Size (kb) 6193.3505859375
No of lines 72136
Duration 0:03:39
Vehicletype ArduCopter
Firmware Version V3.6.8
Firmware Hash 2f409678
Hardware Type
Free Mem 0
Skipped Lines 0
Test: Autotune = UNKNOWN - No ATUN log data
Test: Brownout = GOOD -
Test: Compass = WARN - Moderate change in mag_field (33.21%)
Test: Dupe Log Data = GOOD -
Test: Empty = GOOD -
Test: Event/Failsafe = GOOD -
Test: GPS = GOOD -
Test: IMU Mismatch = WARN - Check vibration or accelerometer calibration. (Mismatch: 0.91, WARN: 0.75, FAIL: 1.50)
Test: Motor Balance = WARN - Motor channel averages = [1554, 1541, 1455, 1459]
Average motor output = 1502
Difference between min and max motor averages = 99
Test: NaNs = FAIL - Found NaN in CTUN.TAlt
Found NaN in CTUN.DSAlt
Test: OpticalFlow = FAIL - FAIL: no optical flow data
Test: Parameters = FAIL - ā€˜THR_MINā€™ not found
Test: PM = GOOD -
Test: Pitch/Roll = GOOD -
Test: Thrust = GOOD -
Test: VCC = UNKNOWN - No CURR log data

I have some comments and some doubts here.

  • The magnetometer included in the GPS unit, on a pedestal, shows little noise but some slight measurement changes that follow average motor current, despite having been calibrated for total current compensation. The magnetometer included in the Pixhawk shows larger steps, and large noise, caused by motor current interference. The system is configured to use the magnetometer in the GPS, of course. Should I just turn off the other magnetometer, or is it a good idea to leave it enabled as a fallback, despite the noise, just in case something very bad happens to the GPS magnetometer?

  • The IMU mismatch surprised me. On the ground the two IMUs seem to agree well. My noise level measured 22 peak and 12 average in Z, and lower in X and Y. Accelerometer calibration was done very carefully at home. Question: Could the reported mismatch be caused in any way by the drone not being level during power-up before the flight? The drone probably wasnā€™t perfectly level at that time, because I live in the mountains and there just isnā€™t any level spot outside the house. But I understand that only the gyros are calibrated at power-up, and a tilted position shouldnā€™t affect that calibration, as long as the drone doesnā€™t move during calibration. Am I missing something?

  • Am I right if I think that the motor balance warning means that my left-hand and right-hand propellers arenā€™t exact mirror copies of each other? Iā€™m assuming that the order of motor throttle values reported follows the standard motor numbering, which means that both of my left-hand spinning motors need a higher throttle setting that both of the right-hand spinning ones.

  • I assume that the other reported fails are due to stuff my drone doesnā€™t have, perhaps also to firmware version differences. Is that correct?

Then I wanted to do what the docs say to do after the first flight, to set up the drone for autotuning. I was suprised to see that MOT_THST_HOVER had set itself to 0.1416938. My drone definitely cannot hover at 14% power, much less at 14% RPM! During motor testing I found that the maximum thrust I can get is slightly more than twice the droneā€™s weight. So I had expected a MOT_THST_HOVER value around 0.45 to 0.5. My MOT_SPIN_MIN is set to 0.15, which produces roughly 200 grams of thrust. MOT_SPIN_ARM is at 0.07, and at that setting all motors spin but there is no detectable thrust. So, what does the MOT_THST_HOVER mean? Is it expressed in a different way or scale than the MOT_SPIN parameters? My stumbling stone is that when I want to follow the docs and set the PSC_ACCZ parameters according to the self-set MOT_THST_HOVER value, PSC_ACCZ_P ends up out of range.

So, how should I continue from here? Set that parameter as stated in the docs, even if thatā€™s out of range, and proceed to autotuning?

1 Like
2

Well, it looks like my post was long enough to discourage everybody from replying! So I will have to reply myself. :rofl:

I tried autotuning, five times, both from loiter and from althold. Within the safe flight time allowed by my battery, 12 minutes, it never completed even the first axis. Log analysis shows that it tries lower and lower values for p and d, getting down to roughly p=0.037 and d=0.0021 by the time I have to land due to the battery running down, and it still wants to go even lower.

So, autotuning failed in my case. Possibly due to flexy frame (cheap F450 clone).

But the copter flies pretty well with the default PID values, so I will temporarily forget about tuning. In the future I hope to build my own frame, stiffer and lighter, then it might be time to try autotuning again - and perhaps upgrade to the latest stable firmware version first.

For those of you who wonder why I havenā€™t done this yet: I fear bricking the Pixhawk. Iā€™m tied to Windows XP due to a lot of old software and hardware I need to use, and since MissionPlanner doesnā€™t work in XP, I have to run it in a virtual machine with Windows 7, and the USB-serial connection from that virtual machine to the Pixhawk is flaky. Good enough to let me set the parameters, and to receive realtime Mavlink data, but it fails every time I try to download a log file, forcing me to take out the SD card and read it in a card reader. I fear that trying to update the firmware over this faulty link might end in disaster.

Iā€™m positively impressed by the stability and easy controllability of this quad, compared to the toy I used previously (Syma X25 pro).

3

The auto-analysis tool has limited value. The trick is to post a link to a .bin log file.
Iā€™ll attempt to check out your info some more later.

EDIT:
ALTHOLD is definitely a great flight mode to be using and next step up is LOITER.
Stabilise is always handy to know and have experience with, especially for testing and tuning in case something goes bad.

Powering up at a tilted position is OK - itā€™s the lack of movement thatā€™s required for the pre-flight calibration. You can always recalibrate your Level Horizon by itself if you think itā€™s not quite right.

PSC_ACCZ P and I values can be set to whatever value you like, or the correct values as calculated - MissionPlanner just throws a warning. I think if you use the Full Parameter List (or Tree) then you dont get those warnings and itā€™s assumed you know what youā€™re doing.
MOT_THST_HOVER seems to be a ā€œpercentageā€ of available thrust between 0 and 1. It is definitely OK to take the learnt value and use that for calculations related to PSC_ACCZ values or notch filters and so on.

If you get a reliable connection (I often use Win10 and MissionPlanner in a VirtualBox VM) then updating to Arducopter 4.0.3 is very well tested and your existing parameters get converted (if required) and you shouldnt need to do addition calibrations.

4

Thanks, Shawn. Good to have the confirmation that while powering up the position doesnā€™t matter, just the absence of motion. Good to know too that you are able to work well with Win10 in Virtualbox! I need to find why my connection apparently overruns and loses data when transferring large files. Iā€™m using Virtualbox too.

Iā€™m still not clear whether I can upgrade to 4.0.3 just so, considering that my Pixhawk is using NuttX with 3.6.8. Can you confirm this?

OK to the other info too. So I will stop worrying about the unusually low throttle value.

Here is the link to the log of my last autotune attempt:

http://ludens.cl/aeromod/drone/00000203.BIN

5

If in doubt upgrade to 3.6.12 first - all the major features and parameters are the same. If youā€™re happy with that working then upgrade to 4.0.3
Accept any prompts to use CHIBIOS.

In that log, Vcc (5 volts DC for the flight controller) is a bit low. Make sure youā€™re not running a telemetry radio or any other high current devices from the flight controller itself. They would need a separate BEC. If youā€™re Vcc is still low you might want to get another ā€œpower brickā€. Youā€™re after about 5.2vdc for the Vcc

Iā€™d probably set INS_GYRO_FILTER,20 (instead of 40) and run autotune again. Fly around in ALTHOLD for a bit so we have some normal (non-Autotune) data in the log. If you change the INS_GYRO_FILTER setting and youā€™re getting oscillations or poor response, you might need to change the PIDs a bit before you are able to run Autotune:
ATC_RAT_RLL_P, 0.15
ATC_RAT_RLL_I, 0.15
ATC_RAT_RLL_D, 0.005
ATC_RAT_PIT_P, 0.15
ATC_RAT_PIT_I, 0.15
ATC_RAT_PIT_D, 0.005

Check your parameters against this helper spreadsheet, if you didnā€™t already:


And the tuning guide if you need it:
https://ardupilot.org/copter/docs/tuning-process-instructions.html

Oneshot can work but thereā€™s probably no advantage on quads this size or larger. My preference is DShot150 if youā€™ve got an aversion to ordinary old PWM. You motors are set up on the main servo outputs 1, 2, 3, and 4 - this is normal and some flight controllers support the non-PWM protocols on those outputs, and some donā€™t. You Pixhawk 2.4.8 clone might - check if your ESCs make a different sound based on their input protocol. Arducopter falls back to PWM if it needs to.
The newer firmware versions have a message that tells you which outputs are doing PWM.

6

I just checked my pixhawk 2.4.8 clone before and after enabling BLHeli and DShot150 - messages are always the same:
3/09/2020 2:57:43 PM : RCOut: PWM:1-14
3/09/2020 2:57:43 PM : fmuv3 00260044 32385109 38383435
3/09/2020 2:57:43 PM : ChibiOS: d4fce84e
3/09/2020 2:57:43 PM : ArduCopter V4.0.3 (ffd08628)

So PWM only on the main servo outputs.

I had to set the AUX outputs SERVO9 -> SERVO12 to functions 33 -> 36 and after a reboot I get the expected messages. Remember to set SERVO1 -> 4 as Function 0.
Always reboot after any motor or battery changes!

3/09/2020 3:07:00 PM : Frame: QUAD
3/09/2020 3:07:00 PM : RCOut: PWM:1-8 DS150:9-12 PWM:13-14
3/09/2020 3:07:00 PM : fmuv3 00260044 32385109 38383435
3/09/2020 3:07:00 PM : ChibiOS: d4fce84e
3/09/2020 3:07:00 PM : ArduCopter V4.0.3 (ffd08628)

Other settings were:
MOT_PWM_TYPE,4 <- choose preferred protocol, faster wont necessarily be better
SERVO_BLH_AUTO,1
BRD_PWM_COUNT,6 <- must be 4 or greater for a quad, 6 for hex

Summary: youā€™re using PWM whether you know it or not. Thatā€™s not so bad, but if you really must use another protocol then configure as per above.

7

Yes, Iā€™m aware that my 5V supply looks very low. I have no telemetry radio nor anything else powered by the APM power module - just the Pixhawk, GPS and RC receiver. But the voltage isnā€™t really that low. Itā€™s 5.14V, measured at the power input connector pins of the Pixhawk, with everything running. I assume that either the internal measurement is inaccurate due to imprecise values of the voltage divider resistors in the Pixhawk, or that this clone Pixhawk has a Schottky diode in series with the 5V input, causing about 0.4V drop.

It also reports the servo voltage to be almost identical to the main 5V supply - but Iā€™m not powering the servo rail at all! I will do so in the future, to be able to use a servo for a cargo grip. A 5.1V 3A BEC has been ordered some time ago but hasnā€™t yet arrived. The actual voltage on the servo rail is now roughly 4.1V, probably due to some leakage in the internal switch, and the lack of any load on the servo rail.

Anyway I donā€™t think that any of this has an effect on the operation of the controller, given that it runs on 3.3V coming from a low drop-out regulator. As long as the internal 5V rail doesnā€™t go below 4V or so, the 3.3V should remain stable.

I will try with INS_GYRO_FILTER=20, when it stops raining.

I did check that spreadsheet, I also read the documentation many times, and set the parameters as seemed most correct for my quad, within the limits of my understanding. But I did not change any PID settings yet. Iā€™m using the default ones. I donā€™t feel much inclination to start manually tuning them, because each iteration would take me a lot of time, since I have no laptop computer, no telemetry radio, and my RC transmitter isnā€™t well suited to setting up for in-flight manual parameter adjustment. So if at some point I can get the autotune to work, great, and if not, I think I can live happily with the default PID parameters. I see no signs of any oscillations or strange behavior. Position holding in loiter mode is good, altitude hold is good too.

When I have a camera on the quad (hopefully in a very few days) it will become more obvious whether I have any oscillations. I will first install the camera without a gimbal, because when I ordered all the parts for the gimbal, I didnā€™t notice that the motors I bought need M1.6 screws, and I have none of those, nor could I buy any here! M2 are my smallest. So I had to order them from China, and wait a month or twoā€¦

I have no aversion to good old PWM. How could I, given that I flew RC planes in the 1980s and 1990sā€¦? I just thought that Dshot150, with its lower latency, should give a little more peace of mind. The less latency one has in a control loop, the less risk there is for oscillations. So I first set up the Pixhawk for Dshot150, and later I noticed that the docs say that it would run in PWM anyway. From the docs I understand that Oneshot is the highest mode supported on the main outputs, so I chose that one - it should have almost as low latency as Dshot150, allowing one update per attitude loop. I havenā€™t measured whether itā€™s actually running in Oneshot now, or still in PWM. I noticed no difference in ESC behavior.

Anyway, the ESCs seem to work well enough in whatever mode the Pixhawk is really using. I think I will leave that as it is, at least until updating the firmware.

8

OK, all good. We all end up reading through the docs many times :slight_smile:

You can definitely update to at least 3.6.12 - thereā€™s some critical fixes included. 4.0.3 is good to go too, itā€™s suitable for all flight controllers.

Iā€™d probably set MOT_PWM_TYPE,0 (and reboot) and do the all-at-one ESC calibration, unless you feel like moving your ESCs to the AUX outputs and changing a few other settings to match.
https://ardupilot.org/copter/docs/esc-calibration.html#all-at-once-calibration

If you think the tuning is not right (visible oscillations, sloppy response or hot motors) just post a link to a .bin log file and we can take a look at it. Even if you think the tuning is good, and just want a second set of eyes checking thingsā€¦

If your quad is flying good then itā€™s not essential to run autotune or mess around with too much. On the other hand it is nice to run autotune and know that PIDs are closer to ideal.
To get Autotune working, you can do one axis at a time.
AUTOTUNE_AXES,1 for roll, 2 for pitch and 4 for yaw
This gives the opportunity to recharge the battery between each axis.
Once they are all done individually you can run all at once, it does go a bit quicker then: AUTOTUNE_AXES,7
I take off in ALTHOLD and fly around, test LOITER to make sure everything is working OK, switch to AUTOTUNE mode and let it go. Reposition if necessary. Once the aircraft stops twitching just bring it back and land, disarm - dont switch out of Autotune mode until after disarmed.

If you are going to run Autotune, do so before adding the camera. Even go as far as taking off any payload if you are going to run Autotune in the future. Lighter is better.

9

I will look into the firmware updating once I have sorted out my USB-serial communication problem.

I had done the ESC calibration, according to the docs, during initial setup. Then I changed to Dshot150, then I discovered that this doesnā€™t work, then I changed to Oneshot, I think that I redid the ESC calibration at that time, but frankly Iā€™m not sure nowā€¦ I will check. Anyway the ESCs seem to be happy.

In fact I had set up the autotune to tune just the roll axis. On the other hand, if I understand the docs correctly, if the parameter is set to 7, and I land after the autotune was successful for roll but not yet for pitch, it would still save the calculated roll parameters. It might actually be best to leave the parameter at 7 at first, so that I get a clear indication that tuning of the roll axis has been completed: By the fact that the vehicle is starting to twitch in pitch. Thatā€™s easier to see than just a stopping of the twitching.

The last sentence in your post touches a point I wondered about a lot, after I read it in the docs. To me it seems incorrect to let the software autotune the vehicle to the most aggressive settings that result in stability, and AFTER THAT change the vehicleā€™s characteristics by adding the gimbal, camera and other stuff! I would think that this will throw the tune out of whack. Specially if the autotuning tries to go as high in the gains as the vehicle can tolerate (and thatā€™s what the docs say), adding off-center mass like a camera setup, drastically increasing the vehicleā€™s moment of inertia, is likely to put the vehicle beyond the stability limit!

I would think that a good method is to first autotune without the camera etc, then put the gains a bit down for safety, install the camera, and then again autotune, as a kind of fine-tuning in the definitive configuration. But the docs donā€™t say such a thing.

I understand that the recommendation to remove the camera and gimbal is because they could wobble, confusing the autotuning routine and preventing convergence. That would be logical. But what good is a perfect tune of the unloaded vehicle, for flying the wobbly camera-loaded vehicle?

Changing the basic characteristics of the vehicle AFTER tuning sounds wrong to me. Am I missing something? Do the developers perhaps assume that the mass and possible resonances of the camera system are negligible compared to the rest of the vehicle?

10

The method used when adding weight (camera, gimbal etc) is to leave the PIDs as calculated by Autotune, but you can reduce these values if you so wish, although thereā€™s no need:
ATC_ACCEL_Y_MAX
ATC_ACCEL_R_MAX
ATC_ACCEL_P_MAX

You can also increase ATC_INPUT_TC for a softer/smoother RC feel - around 0.20 or 0.22 is good usually.

The PIDs are actually (somewhat) dependent on your props weight, drag, ESC response and braking plus a range of other factors. A lot of that doesnā€™t change just because you add weight. This is why we dont have another spreadsheet with a set of PIDs based on prop size and frame size, or a few other simple variable that could just be plugged in.
Iā€™m still learning all these things tooā€¦

11

It still seems incorrect to me. I have tuned PIDs before, in devices such as robotic arms, astronomical instruments, a boatā€™s autopilot, and also in purely electronic things such as switching power supplies. Tuning a PID is basically getting the error amplifier gain as high as possible, in each of its three parts, to get the total loop to respond as quickly, accurately and cleanly as possible, without getting too close to self-oscillation. Everything that has an influence on any part of the control loop will affect the tuning. Even if most things stay constant, changing one single thing already requires a different tuning. If mass is added, or if some flexibility changes, it does require a change of the PID parameters to return to the optimal performance.

I donā€™t see why a quadcopter should be different in this regard. If, say, the pitch axis is tuned to optimum without the camera, it means that itā€™s tuned so that a sudden change in the desired pitch will make the actual pitch change to the new value as fast, as precisely, and with as little overshoot as possible. If now a camera is added, located far down/forward from the mass center of the vehicle, the additional moment of inertia will require a different control loop response: The props need to be driven so that they produce a larger torque in the pitch axis, to accelerate it with the camera in place just like it did before, and when the vehicle is reaching the desired new pitch angle, the reverse action of the props also needs to be stronger, to keep the larger inertia from making the vehicle overshoot the target angle. Unless Arducopter has some mechanism to automatically sense and learn any changes in the vehicleā€™s behavior, adding a camera would require at least a touch-up of the tune.

As far as I understand Arducopter so far, this automatic sensing mechanism is precisely the autotuning functionality, but it doesnā€™t run continuously. So I do think that it would be most logical to perform a final autotuning when the vehicle is in its final configuration.

If mass is added with the same distribution as the unloaded vehicleā€™s mass, it might be possible to automatically compensate for that because the throttle setting for hover will be higher. So if all gains act proportionally to this hover throttle setting, there should be a good degree of automatic compensation for additional mass. But I donā€™t see how this could work if the added mass is located far away from the vehicleā€™s center of mass, as would be the case with a camera. Just sensing the added mass tells nothing about the added moment of inertia.

I suspect that most people are flying with PID gains far below those that would result in the best possible control performance, which allows a lot of headroom for changing the vehicleā€™s characteristics and still not risking oscillation.

On the other matter: I made an attempt this morning to upgrade the firmware. NO WAY. When I try, after chosing version 4.0.3, Mission Planner doesnā€™t detect the Pixhawk, and asks me to disconnect and reconnect the USB. As soon as I disconnect it, Mission Planner hangs, and the only way to bring it out of that is to shut down the virtual machine in which it runs. I donā€™t see how to fix this when running Mission Planner in a virtual machine. Virtualbox, when set up to pass through a serial port, requires this port to be present in the first place. But when unplugging the Pixhawk, the USB-serial driver de-registers the virtual serial port in Windows, and VirtualBox canā€™t handle that.

So I searched which is the latest version of Mission Planner that works in XP. From what I found in relevant posts, thatā€™s 1.3.34. So I downloaded and installed that version on my main machine, in XP. Indeed it starts up perfectly, but it canā€™t communicate with my Pixhawk at all! When I ask it to connect, after a 30 second timeout it tells me ā€œNo Heartbeat Packets Receivedā€, and thatā€™s it. Thatā€™s with the same USB-serial driver that works well via VirtualBox into the virtual machine with Win7.

So it looks like I wonā€™t be able to update the firmware until I either buy a new PC, which is not in the plans for now, or have a chance to borrow one, which is unlikely in these COVID times.

I think I will stop worrying about all this, install the camera and go fly! After all my quad flies pretty well with version 3.6.8 and the default PID parameters.

12

I got the autotune to workā€¦ And the method was unconventional: Install the camera! :grinning:

After installing the camera, I noticed an enormous amount of vibration that I wasnā€™t aware of. There was so much jello effect that the video was totally useless. So I followed the instructions to do FFT analysis, and found the vibration peak to be at 88Hz (propeller rotation speed), at a level of about 400 (I donā€™t know what units the FFT display uses). The normal vibe plots always showed good levels, significantly below 30. Surely those are after low-pass filtering.

Obviously simple static-balancing my propellers wasnā€™t good enough. So I spent several days trying to straighten crooked propellers, machining down hub seats, then dynamically balancing my props using home methods (very slow!), and since I was at it, I also dynamically balanced my motors. After that the peak on the FFT plot went down to 90. A big improvement, but still far from perfect.

The jello effect is now much smaller. Still present, still objectionable, but I can look at the video without getting seasick. And the autotuning worked perfectly, taking around 3 minutes per axis. The response of my quad is now quick, clean and precise.

I guess in the long run I will need a stiffer frame than the clone F450, and there is a lot of room to improve the damping and isolation of my camera mount.

I would wish for better propellers. The Gemfan nylon-glass ones Iā€™m using arenā€™t straight, the blades are at about 178 to 179 degrees between them! The HJ carbon fiber ones are straighter and lighter, but have poor efficiency due to the lack of a real airfoil, and a negative angle of incidence! Their aerodynamic balance is also very poor, with the two blades being obviously different. I now ordered three more types of propellers, hoping to get any that are straight and efficient. If they also came balanced, that would be a bonus, but we shouldnā€™t ask that much! :stuck_out_tongue_winking_eye:

Even the propeller nuts of my motors (Readytosky 2212 930KV) are severely out of balance! And I canā€™t balance those, because the threads sit so loosely on the studs that the nuts end up in a different position every time I install them. I should make new nuts. No problem with the normally threaded ones, on my lathe, but I lack a lathe tool to cut inner left threads, for the left nutsā€¦

Life isnā€™t easyā€¦ :sweat_smile:

Anyway, Iā€™m having fun. And that was the whole idea behind getting into drones.

13

Hi Manfred,
Good to hear you got everything going OK. Iā€™m impressed by your persistence at getting the props and motors balanced correctly and a successful Autotune.
Did you manage to get a firmware update done and put the Harmonic Notch filter settings in place? or you just used the FFT to see the problem?

I have not been able to do a firmware update through virtualbox unfortunately although everything else works OK, but I can via Linux using QGroundControl or MissionPlanner (with mono installed).

14

Hi Shawn,
No, I havenā€™t updated the firmware yet. But I did try the simple notch filter offered by the 3.6.8 version. It made no difference that I could detect. I suspect that this is because the vibration frequency of my quad, around 88Hz, is much higher than the low-pass filter cutoffs Iā€™m using, 40 and 20Hz. So the lowpass filters get rid of the 88Hz interference, and the notch filter doesnā€™t do much. I then turned off the notch filter again, to save the delay it causes. The autotuning was done without the notch filter.

I suspect that the problems with autotuning while the 88Hz vibration was strong, was not due to the 88Hz signal proper, but due to low-frequency mixing products caused by motors spinning at slightly different speeds.

Thanks for the hint about using Linux! I do have three different flavors of Linux installed in as many virtual machines, but to be honest, I have never learned to use Linux for real, and havenā€™t ever done anything useful in that OS. Every attempt has ended in frustration. I would really need to learn Linux from ground zero, devoting a lot of time to it, and I have no motivation for that. But installing QGroundControl or MissionPlanner in Linux should be within my capabilitiesā€¦ I even googled what Mono is! :slight_smile:

On the other hand, I donā€™t see much reason for upgrading the firmware. 3.6.8 is working very well for me. Iā€™m a big believer in the rule ā€œif it ainā€™t broken, donā€™t fix itā€. I think that I will try to upgrade the firmware only when I get to the point where I need any of the new functions that 3.6.8 doesnā€™t have.

15

4.0.4 brings a dynamic notch filter and fixes at least a I2C interrupt storm issue in 3.6.x
:slight_smile: you decide.

It aintā€™t broken until it crashes :slight_smile:

16

I donā€™t seem to need the dynamic notch filter. I see it useful in the case of copters that have the main vibration frequency falling inside the bandwidth of the lowpass filters.

I just read up about the I2C interrupt storm issue. If I understand this correctly, it affects version 3.6.10 running on ChibiOS, and was fixed in 3.6.11. But Iā€™m using 3.6.8 running on NuttX. So I hope that my setup is not affected by this problem!

If I knew for certain that the latest stable version is 100% free from any problems, of course I would like to install it and be safe. But in a software as complex as this, that runs on many different platforms and with a huge range of possible peripherials and configurations, itā€™s probably impossible to guarantee the absence of bugs, no matter how carefully the developers work. So I have no certainty, and perhaps not even the likelihood, that a freshly released new version is safer than a well-known old version that has seen many flying hours by many users.

Thatā€™s why I tend to be hesitant about upgrading every time a new version is released. Not just with Ardupilot, but with all software I use. I really believe that advanced users should install the latest versions, while beginners like me are better served by specific older versions that are known to work well enough in the given setup, even if they lack some new features.

Anyway, at this time I donā€™t even have the means to upgrade. I first need to get a modern Windows, which means buying a new computer, or else try to go the Linux route mentioned by Shawn. If my copter crashes, that might be the motivation I need! :stuck_out_tongue_winking_eye:

17

Yes, you are correct in your reasoning. But 3.6.12 has a lot more users then 3.6.8. And 3.6.12 is very old already. So it fits the requirements you are looking for.