I’ve been working on reducing vibes on my Tarot X4 - and have made progress and getting them reduced.
Yesterday during an autotune flight, I got a huge momentary vibe spike. It visibly unsettled the copter. I landed immediately to investigate. I thought perhaps a part might have come loose. I found nothing. I continued after the inspection and completed a new autotune flight.
Today on an auto mission, I got a second huge vibe spike - a spike high enough to cause an EKF lane switch. I did an RTL to investigate - and again found no mechanical issues.
Some interesting notes: 1) The clipping on ACC-0 and ACC-1 was huge - but the clipping on ACC-3 was moderate. 2) There is an associated spike in current - presumably caused by the autopilot commanding the motors to recover.
With so many possible points of failure on a copter such as this, it’s hard to know where to begin. Not finding any mechanical defects, my first thought is some sort of intermittent short - or perhaps a glitch in an ESC.
Another thought is the Orange Cube itself. This copter is using my very first Orange Cube and ADSB Carrier Board - that I bought about 3 years ago. It doesn’t have more than a few hundred flights on it - but the odd clipping behavior makes me wonder if maybe it might be worth swapping it out.
This will be an interesting problem to trouble shoot. I’d appreciate any and all comments.
One first step was I’ve installed Copter 4.4. I don’t know if it will make any difference - but it did solve my odd GPS pre-arm problem. My GPS appears to be slow in confirming it’s configuration step. In Copter 4.3 it would issue a pre-arm warning. Now it does not - it just logs a message that it’s waiting for the GPS configuration.
Vibrations are still excessive before and after the incident, but the actual spike in vibrations (and subsequent lane switch) is most likely caused by a mechanical issue.
The vibrations and clip counts spike, but voltage and current are only affected by attitude control after the fact - it’s likely voltage and current, such as a short, are not involved in the cause.
Just thinking of ruling out any sources of vibrations.
What if you use motor test to run the motors without props and adapters to check for vibrations?
Refit the folding prop adapters, test again, and so on…
Can you stiffen the frame/base plates? More connecting stand-offs between upper and lower plates?
Leave the landing gear lowered, disconnect the servo wire so they dont try to move. Use something as simple as a rubber band between legs, or some form of connection between lower portions of the landing gear and the frame to dampen vibrations.
EDIT:
Looking at ESC RPM, the traces are relatively steady before and after after the incident, but in the 2 to 3 seconds leading up to the incident, RPM becomes increasingly unsteady and it appears Motor1 (servo9) has the most trouble following demands.
After the lane change the demand and RPM all go back to behaving very nicely. So that points to one IMU being better able to cope with vibrations than another, but of course that’s why we have multiple different IMUs.
You could change the EK3_PRIMARY value to mask the root cause and potentially fly nicer, but if there’s another issue and EKF switches to another (worse) lane you could be in worse trouble.
EDIT AGAIN
In fact you should definitely set EK3_PRIMARY,1
which is the correct (newish) default value for Cube Orange
but then continue to investigate the vibrations and cause of the spike.
Regarding vibe levels - in hover tests the vibes are now quite low - toping out at about 15. It’s when in flight that vibes come up. With folding arms and retractable landing gear - I’m not sure this can be avoided. But I’d be delighted to be proven wrong about this.
I ran a set of plots for each vibe spike incident - and each motor. From these plots it seems to me that the RPM is responding to the vibe spike. Interestingly, the RCOU values don’t really reflect the RPM - perhaps because I’m using Dshot 600.
Lastly, when I set up this Cube for this copter I did the Mission Planner “reset to defaults” option - as this Cube had been used on other copters with previous versions. It did not reset EK3_PRIMARY to 1 - which you point out is now the default. I’m going to mention this in a post in the Mission Planner section.
