Yaw instability on octarotor x configuration

[Geodrone21]

Hi everyone. I am writting to address an issue of yaw instability that we are dealing with, in our octorotor x drone (designed by us).

The drone is succesfull at maintaining balance for roll and pitch but fails to do so for yaw. The flight is performed in position mode (where a steady heading should be maintained). The direction of (yaw) rotation seems to be random (sometimes CW and others CCW). Also the drone does not respond to the commands of the yaw stick of our remote controller, while it does for the other 2 (pitch and roll). We are using pixhawk 4 pilot at octorotor x configuration. The remote controller is FrSky Taranis X9D SE. Note that the drone has a diameter of 1.25m of the motors circle and weights about 9kg. The Pixhawk module has only been used to provide power supply and battery voltage reading to the PX-4. The ESCs power supply and signals are on independent circuits.

in order to eliminate possible sources of error we have:

-tested 3 different pixhawk-4 pilots -downgraded the firmware to versions 1.8.2, 1.10.1 & 1.10.2 -changed the position of the px4 on the drone to eliminate the possibility of em interference -checked the heading angle (magnetometer) in the telemetry to verify that it works -tested with 2 different RX8R receivers (note that our RC controller works well with other drones) -used 2 dfifferent GPS units (one Holybro GPS module M8N and one Holybro H-RTK GNSS). They both work fine as we can see in the telemetry.

None of the above had any impact and the issue remains.

We are planning to test ESCs and motors next. Also we are not sure if using the Pixhawk module to supply power and signal to the ESCs could have a positive impact on this issue. Any similar experiences anyone?

[bresch]

Hi @Geodrone21 ,

It's probably due to a too weak yaw authority or poor yaw rate tuning. Do you have a log to share?

[Geodrone21]

Thank you for your answer. So far we have kept the default pixhawk values for these parameters. I have uploaded a log file from one flight. Note that this particular flight is one of the most stable we have managed to have. the drone succeeded to hover steadily for about 12 seconds before beginning to spin around the vertical axis. Usually this starts right after the take off. 16_38_46.zip

[Geodrone21]

https://review.px4.io/plot_app?log=69568244-59b2-4ebe-b2a7-a9530a294df1

the link above is the same log uploaded

[bresch]

@Geodrone21 To me, it looks like the rotors are spinning in the wrong direction. Please double check: https://docs.px4.io/v1.11/en/airframes/airframe_reference.html#octorotor-x

[Geodrone21]

@bresch We have checked the motor directions and they are correct.

Also after reviewing the followign diagrams in the log file we conclude that: The yaw (estimated) angle begins from 185deg (or -175deg) and decreases, meaning that the drone has a negative rotation about the z axis (see 1st figure) or a CCW rotation when the drone is seen from above (top view). This is also in accordance to the video footage of the flight. Since the yaw setpoint remains at 185deg, the pilot builds up gradually a positive yaw rate setpoint trying to return the drone to its original heading. Since there is no such response from the drone, the pilot increases further the positive yaw rate setpoint to the maximum value 200deg/s. Since the drone rotates CCW the pilot needs to apply CW moment on it. In order to achieve this it needs to increase the RPM of the CCW motors (and reduce the CW ones). [this is because a CCW rotation on the rotor creates a CW rotation on the stator] If we now observe the actuator outputs diagram, we see that outputs 2,3,4,5 are the ones that increase their PWM on duration. Assuming that output 0 corresponds to motor 1, output 1 corresponds to motor 2..., outputs 2,3,4,5 correspond to motors 3,4,5,6 If we check the octorotor-x airframe reference these are the CCW motors. So this is correct to my point of view. Given the above why do you assume that the rotors are spinning in the wrong direction. Did you observe something that we are missing in the log file? Please clarify.

[bresch]

Given the above why do you assume that the rotors are spinning in the wrong direction. Did you observe something that we are missing in the log file?

Because as you said, there is nothing wrong in the log. The autopilot is trying to counteract the yaw error but the effect is amplified, this means that the drone is producing yaw torque in the wrong direction. This is usually caused by:

1. The rotors are spinning in the wrong direction (this is the most common mistake, but you said that you already checked)
2. The motors are tilted such that the yaw torque produced by the thrust is stronger and opposed to the torque produced by the drag of the propeller

[Geodrone21]

Dear Bresch, Thank you for your responses. The issue is resolved and it was caused due to no.2 of the reasons that you mention in your latest answer. Below you can find the description of the reason that caused the issue and how it was resolved:

   Our octarotor consists of 4 main arms and each of them is divided in 2 branches as shown in the sketch below

According to the Pixhawk Octorotor x airframe the red motors are rotating clockwise while the blue ones are rotating counter clock wise. So each one of the 4 main arms has a blue and a red motor. When the pilot wants to rotate the drone around the vertical axis (yaw) counter-clock wise it orders the red motors to raise their RPM and the blue motors to reduce theirs. This also increases the thrust of the red motors and reduces the thrust of the blue. This causes a minor deformation on the arm (the red motor is raised higher than the blue and the thrust vectors are no longer vertical.

So a horizontal component (along the secondary arm) is produced. This can be analyzed to an axial component (towards the center of the drone) and a circumferential component.

The axial component is canceled from the vector of the oposite motor. However the circumferential ones are not canceled as all 4 have the same rotational direction This causes the drone to rotate clock wise (in the oposite direction than what the pilot intended).

The solution was to change the directions of rotation of the motors (red motors counter-clock wise, blue motors clockwise). This way the circumferential forces that are generated due to the arm deformation are helping to rotate the drone in accordance to what the pilot originally intented.

[bresch]

@Geodrone21 I'm glad it works now! Thanks for the feedback, I've often seen rotors not properly aligned causing this issue but I never through about this geometry. The good thing now, is that by changing the direction of rotation, the bending even improves the yaw effectiveness (compared to a rigid structure). However I hope that the arms won't fatigue too quickly :)

[Geodrone21]

@bresch Yes indeed it does improve the yaw effectiveness!
However we are now redesigning the Y link to reduce the deformations - among other features we want to add- (even though there is no issue regarding the stresses - simulation showed that max stresses are well below the material tensile stress and no issue should be expected regarding fatigue - according to relevant bibliography). Also, we are now taking this into account for our other desings too (choosing the correct direction of rotation for the motors, to make sure that deformations will improve the yaw effectivness- even if the expected deformations are negligible) Thank you too for the valuable time and thoughts that you shared with us! :-)