AutoMission succeeds / fails depending on takeoff position

[o_zoeller (Oliver Zöller)]

Hi ArduPlane community and happy easter!

Some recent flights with our Nimbus VTOL (from MyFlyDream) have caused some head scratching for us.

The aircraft is configured like this:
-Nimbus 1800 plane w/ VTOL conversion
-12Ah 6S battery
-Taranis X8R / X9D+ combo
-no airspeed sensor, GPS only
-no payload in these flights
-GPS fix arming check is enabled

We bought two of these aircraft for long range (BVLOS) inspection missions in Germany. After receiving them, we have done lots of flights getting used to it and tuning it, working up to automatic flight modes (Loiter / RTL / AUTO).

We have uploaded a test AUTO mission (auto takeoff at Location A, transition, waypoint flight, transition, auto land) and had no problems.

The next time we uploaded a similar mission nearby, but in a more accessible takeoff location. (VTOL_Takeoff to 40m, waypoints, then land). The mission is unchanged in the following 4 flights and we had great conditions with close to 0 wind for all four flights.

1st flight (Takeoff Location B): Aircraft takes off, immediately rolls hard right (towards 1st waypoint) and seems to disregard the VTOL takeoff to 40m. Almost crashed into a bush before I took over (QLOITER / QSTABILIZE) and landed. We blamed it on bad GPS signal and chose to go back to the previously working takeoff location where we have more space in all directions.

Log: https://drive.google.com/file/d/1SCHDuqP6n18aqG5xBaw1xw9s2XJV2puO/view?usp=sharing

2nd flight (Takeoff Location A): Mission works with no problems, other than a bit of toilet bowling in the beginning.

Log: https://drive.google.com/open?id=11JGOn3-nJX4VFvQiJVvxcQG_IN9n5X7N

3rd flight (Takeoff Location A): Mission works with no problems.

Log: https://drive.google.com/open?id=1A2R8LHffwwbM7ZhuaqIgfOLyIQ1q-oGa

4th flight (Takeoff Location B): Went back to the first location and chose to do a QLoiter first to verify GPS, then land, disarm and start the Auto Mission without power cycling. Did just that, the aircraft did the same thing as in the first flight. This time, I couldn’t get it back under control and it crashed into a bush. Could not disarm, props kept spinning even at 0 throttle. It then became airborne again, crashed into a second bush where I could disarm it. Fortunately, only 2 props broke and the aircraft seems fine.

Log: https://drive.google.com/open?id=1fFfP2pGKGEmzMHk5L1Czu66v0YvYE099

Now my questions:

1. Is this behaviour caused by the aircraft being too close to the first waypoint on takeoff? The only difference between the 4 flights seems to be the takeoff location. If not, what could be the reason for this? (Distance from Takeoff-Point to first waypoint is more than 100 meters, so much more than WP_Radius)

2. The aircraft was delivered basically flyable with V3.8.2-dev. We chose not to change it in order not to mess up any settings. Are there known problems in that code that could cause this?

Thank you very much for your time and effort!

Best wishes from Hamburg and stay healthy
Oliver

[peterbarker]

Is this behaviour caused by the aircraft being too close to the first waypoint on takeoff? The only difference between the 4 flights seems to be the
takeoff location. If not, what could be the reason for this?

No, the code is pretty clear about requiring the height be met - esp. in
this older version of the code.

Please check your compass orientation is correct. Certainly doesn’t look
pretty in the logs. My guess is your subsequent flights went better as
the compass will be ignored once it can be infered from the GPS.

Sorry, I haven’t delved too hard into your logs - but if you can verify
the compass is in the incorrect orientation.

https://ardupilot.org/copter/docs/common-compass-setup-advanced.html#checking-compass-orientation

Your compasses seem to agree with one-another - so also check your AHRS
orientation.

The aircraft was delivered basically flyable with V3.8.2-dev. We chose not to change it in order not to mess up any settings. Are there known problems
in that code that could cause this?

It’s ancient and unsupported. Hopefully the vendor has an upgrade path
for you!

Oliver

Peter

[peterbarker]

This graph is what I’m basing my “check orientation” comment on. The predicted field comes from the world-magnetic-model tables - and your compass isn’t remotely close.

I’m not sure this is within the realm of a calibration issue, which is why I suggest checking orientation first.

[o_zoeller (Oliver Zöller)]

Hi Peter,

thank you for taking the time!

@peterbarker

but if you can verify
the compass is in the incorrect orientation.

The Cube is mounted in AHRS Orientation 6 (Yaw270) which is in line with the parameters that were set by the vendor. The GPS module (with the only external compass) is mounted facing forward.

Looking into compass settings, what I stumbled upon is this:

Compass_Extern2 = 0
Compass_Extern3 = 0
Compass_External = 1

From which I infer: Compass 1 is mounted externally, Compass 2 and 3 are the Cube’s internal compasses.

Compass_Orient = 6
Compass_Orient2 = 0
Compass_Orient3 = 0

Here’s what I don’t understand. Compasses 2 and 3 are using AHRS_Orient since they’re internal. But shouldn’t Compass_Orient be set to 0 since it is relative to the frame and not the autopilot?

Compass_Primary = 0

So it is using the externally mounted Compass 1 primarily, but thinks the frame is 90° off?

Compass_Use = 1
Compass_Use2 = 0
Compass_Use3 = 0

And it is not using the other two?

@peterbarker

It’s ancient and unsupported. Hopefully the vendor has an upgrade path
for you!

We will ask for that, but do not have a lot of hope. Is there any documentation to follow for upgrading from Plane 3 to 4?

@peterbarker

I’m not sure this is within the realm of a calibration issue, which is why I suggest checking orientation first.

Compass_Cal_Fit is set to 32 (Relaxed), so the calibration could be a bit off as well. If the above isn’t the problem, I’ll recalibrate on both aircraft.

Thank you again
Oliver