Strange Z Vibrations (Not an ardupilot issue)

I have got strange behaviour with Z axis vibrations.

Basically, up to a certain current, all vibrations, inclusing Z, are rather low, at hover current of 20 A it is around 6…8, while XY are around 10…12, but from a certain current, around 38 A, it begins to shoot up, and with 45 A it is around 100 and with constant clipping, the other vibes, XY climb also somewhat, but stay below 50…60. I discovered it first at high speeds, above 80 km/h, but then also at fast climbs, so that I think it is not related to airframe - airflow interaction. The motor RPM output and RCOUT are also stable and without oscillations. The airframe is also very rigid, maybe too rigid (if you hit one arm with something hard, there is reverbating sound)?

My hypothesis was that the frame enters some resonance frequency.

Now, I tied down the copter and ran motor tests using the MP motor test feature and observed the Vibe. This time, unfortunately, even at 100 % power and 70 A the maximum Vibes were around 5…10, zero clipping, and the Vibe did not show any predominance of any axis. So now I am not sure if it is resonance related or not.

The frame is a DIY test build.

The vibrations during one flight were so bad that the FPV camera lens turned and got out of focus, battery shifted despite straps, and copter entered emergency EKF mode.


I am curious how do you prevent the round carbon arm tube from rolling.
How do you ensure the arm tube and the frame body maintain level.

Basically, I make complete arms with motor base plates, then using a table and small wooden blocks for getting a perfect level between the motor plates and perfect geometry, then I preglue the four arms and the main body with instant glue. After that I fiberglass the arms, takes about 48 hours to dry. The level error between the blades is less than 5 mm. Now you always can use shims to get a perfect level, but at 5 mm it is less than 0.5 degrees.

The arms are glued at the bottom using fiberglass, and also wrapped with carbon fibers. Compared to DJIs I have, Phantom, Mavic, this frame feels 3 … 4 times more solid, I can not really twist the arms at all, while in DJI there is some play

I made another test flight, and it seems that the problem stems from airflow. I was able to get 1000 W and vertical climb rate of 17 m/s without major vibrations, but with 70 km/h and some 600 W the Vibes go through the roof.

I just wonder, it is the arms or the body that generates such enormous vibration? Because the arms are also pretty solid.

Since the copter flies really well under a certain speed, I am now thinking of implementing some LUA script which would reduce power/speed when the vibes go too high

Isn’t it more straightforward to use various parameters to limit it if you already know the limit and vibration going high will not happen?

LAND_SPEED
LOIT_SPEED
PILOT_SPEED_DN
PILOT_SPEED_UP
RTL_SPEED
WPNAV_SPEED
WPNAV_SPEED_DN
WPNAV_SPEED_UP

There is almost no way of knowing the air speed… If there is a strong wind, then it will not do…

Eh, yes we need AI to know the wind speed in advance.

Having said that, assuming the data collection is under 0 wind conditions (for example, hangar), the vehicle movement will be equivalent to the wind speed. Of course, in reality, there are headwinds, tailwinds, sidewind, upwinds, downwinds, etc.

So, if the limit is set, when the pilot pitches forward and there is a headwind, under full stick pitch forward, the amount of RPM in the hanger will differ in this case. If Lua script is doing the mission flying, maybe your idea is possible; one source of control, what about when a human is flying? Will it introduce unknown safety?

Hi @Michail_Belov,

Again, I haven’t read the entire thread but I wanted to add that AP does include wind estimation even on copters without an airspeed sensor. It’s slightly tricky to setup though.

EDIT: ah, I see you’ve already discovered this in another thread

Couldn’t you still iteratively increase/decrease the speed parameters in real-time to adjust for winds?

i.e. when flying in a headwind vibes will generally be higher so your script running in real-time would step down ground speed until at an acceptable level - opposite when flying with say a tail wind. Running the iteration loop at once a second should be more than enough.

I have pretty much solved the problem temporarily using a Lua script. It measures vibrations in Z, once over a certain threshold (40), Lua checks the power, if over a certain limit (500 W), it begins to reduce the maximum power and also maximum angle.

Fly in low wind conditions in a wide open space, does it matter how well the Center-Gravity of the drone is positioned? A part of the tedious is determining the EK3_DRAG_MCOEF.

Is there a team exploring tools or web tools to streamline the process for both EK3_DRAG_MCOEF and BARO1_WCF_xxx?

Not sure why CG should have a play in determining drag… It should not have almost any impact. The potential drag differences depend on attitude of the copter (but to very small extent, compared to planes), but attitude is not dependent on CG. The only area where CG cold have a play is that motors at higher power are less efficent, so that if you have a severely disbalanced copter, where motors run let us say at power of 30 % and 70 % then there would be a noticeable difference in power requirement when moving in one direction and the other.

Same thing would be even more pronounced if you have both an offset CG to one side and the CG is also above or below the motor line. In that case, the CG would shift considerably when inclining the copter to one side or the other.

Have you collected such EK3_DRAG_MCOEF data before? Imagine you do the data collection in perfect no-wind conditions in a hangar.

Hi @Jai.GAY,

Some time ago I created a Lua script to do the calibration (the code is here) but I ran out of time before other projects pushed it onto the back burner. I think since then I’ve just manually changed EK3_DRAG_MCOEF until the EKF comes up with a reasonable value. That’s not very scientific though and the results have not been as good as what we achieved with the Hexsoon EDU450.