Unstable flight control with offboard commands

ArduCopter
1

We have autonomous flight software that produces TRPY (thrust-roll-pitch-yaw) commands at 50 Hz. In PX4 this is supported by the built-in OFFBOARD mode. Porting to ArduCopter, we made our own offboard mode, which is very similar to Guided_NoGPS except you provide raw thrust instead of altitude. In the log I will attach, it shows as an unknown mode.

When attempting to take off using this offboard mode, the vehicle went unstable right away. In the log you’ll see the pilot switch to STABILIZE and sort of, almost, not really, stick the landing.

I have a few theories as to what went wrong:

  • Maybe the gains are too soft and the vehicle is too slow to respond to the TRPY commands, leading to unstable control. However, the vehicle is stable and responsive in manual flight
  • There could be a math error in transforming the commands to the vehicle frame (I hope it’s this because that would be easy to fix, but I haven’t been able to prove it)
  • Something else I haven’t thought of

I noticed that there is a large yaw reset soon after arming the motors. This is a potential problem for me as I’m using the initial yaw value to align the Pixhawk frame with my internal map. If ArduCopter is going to be randomly jumping the yaw whenever it wants to, it’s not going to be aligned. Is there a way to completely disable yaw resets? I am not using a GPS and I don’t care about magnetic north, I just want a consistent relative heading.

Here’s some plots from the log. This is a Quad X configuration, so I’ve crudely plotted the “RPY motor effort” using the following linear combinations of SERVO_OUTPUT_RAW:

  • R = -C1 + C2 + C3 - C4
  • P = C1 - C2 + C3 - C4
  • Y = C1 + C2 - C3 - C4
    This allows me to see what the vehicle is “trying” to do, attitude-wise, with respect to the body frame. However, it does not match up with the attitude, and I would love to know why.

Again note that MAVExplorer shows UNKNOWN for our custom offboard mode.

image
image1041×513 81.3 KB

image
image1060×521 76 KB

image
image1075×515 61 KB

Do you see an obvious reason why the control became unstable, or why the motor effort plots don’t make much sense? And how can I avoid huge yaw resets like the one in the beginning?

Full log attached: log_37_2020-10-12-17-41-52.bin (876 KB)

2

Did you followed the arducopter step-by-step tuning process instructions ?

After that did you performed a autotune with no wind?

3

Yes, autotune was performed outside in still air.

4

Were all tuning process instruction steps take before autotune?

5

Not by me, we purchased this drone with tuned gains, but yes the drone with current payload was tuned manually to eliminate overshoot and oscillations. In fact I believe it was done with help from the Partners program.

6

Just out of curiosity, why are you moving to ardupilot? Are not happy with PX4?

7

A couple reasons, it seems like a lot of vendors are preferring ArduPilot, one in particular has an odd motor configuration that seems better supported. Also, for some reason, ArduPilot reports a lower hover throttle than PX4, for the same platform/payload, which implies that there’s more control margin to command aggressive acceleration. However, if it’s not stable at all, kinda negates that benefit :wink:

8

I realized that motor effort is, of course, in the body frame. So when applying a rotation based on the current yaw, the roll and pitch plots make a bit more sense:

image
image1040×927 151 KB

9

My main questions when looking at these motor effort plots are:

  1. Why is the yaw effort so erratic?
  2. Why did the vehicle decide to pitch down immediately upon takeoff? At about 8.25s in the pitch plot, it lurches down but there was no command to do that.