Plane crash during Auto TakeOff

I did two more tests in TakeOff mode. One overhead launch. One level hand throw. Both failed due to the right roll.

First Over Hean launch. This one got up high enough. But the plane kept rolling right and cannot recover.
Video: https://youtu.be/IXctLiIwU6g
Bin Log: https://drive.google.com/file/d/1cI1DywIN9ifn1APNZhhLqCxXkbAiiw6P/view?usp=sharing
From the bin log, it shows the plane rolled right to 80 degree and full aileron. But it still cannot recover and lead to the crash.

Second level TakeOff mode hand launch. It’s the same right roll and crashed.
Video: https://youtu.be/6HfcH4qDqqM
Bin Log: https://drive.google.com/file/d/1MzT1XJMYEqXxzyBPGWhOdz89GY8PRmn_/view?usp=sharing

It seems my plane has some issue with recovering from rolling right. I checked the range of the ailerons. Both left and right have the same throw.

Any suggestions on what I should check and further investigate the right roll issue?

Have you verified the lateral C of G? If it’s always rolling right, is the right side of the plane heavier? Are you pushing down with your thumb or grip when you release the plane? If it’s rolling right is the right elevon going down?

lateral CG is balanced. same weight both side. no grip when release. checked FBWA the right elevon went down when rolling right. It’s weird same plane setup sucessful two daus ago. But it rolled right and crashed 4 times after that.

Check to see that control surfaces deflect in correct direction in BOTH manual and any of the stabilized modes ( including auto ) . If you have things reversed in both your radio AND your arduplane setup that for me is a red flag .
Check to see what your board orientation is set at. AHRS_ORIENTATION should be set at 0 if your FC is installed in the normal orientation ( top side facing up , arrow facing straight forward ) . Otherwise set this parameter to match your installation .
Finally , I’m not sure if this one would cause your crash but remember to have plane facing the same direction as you intend to take off in when you boot up and initialize IMU .

Thanks for the reply. I confirmed the deflect and had one successful flight before.

The board is 90 yaw and the setting matched.

It’s my first time heard about the final point. I place plane facing north when initialize IMU since there’s no compass. If it’s not facing north, the direction is not correct when rotate the plane before takeoff. Could you give more information about why need to face the plane to the takeoff direction other than north during initialization?

You’ll find it in the Wiki . Once again I’m not sure if violating that one is that serious .
I learned about it the hard way one day . I initialized plane on the ground , got gps lock , etc , etc , then something happened at the field where I had to launch in another direction . I was using auto launch like you are . I threw the plane and it climbed about 20 feet , rolled over on it’s back and proceeded to do a 180 and head in the direction I initialized the plane in . I killed the throttle and let it crash not knowing what would happen next .

Double checked wiki https://ardupilot.org/plane/docs/takeoff-mode.html

"The plane will try to hold its heading during takeoff, with the initial heading set by the direction the plane is facing when the takeoff starts. "

It seems it’s the direction takeoff starts not the direction during initializing when battery connect power on.

Can someone clarify this?

The direction the plane is facing when you trigger take off mode armed.

Well… its definitely as the Wiki says - when we unsupress the throttle
we lock in that heading - and not before.

Do you think the wiki description needs clarification?

If so, do you have any suggestion?

We could explicitly mention it’s nothing to do with heading-at-power-on
(which FWIU is used by some “just-get-me-home” autopilots). Note that
there are several good reasons for us not to do that - one good one is
that we might not really know our heading if you don’t have a compass (we
then generally require movement to determine our heading).

Painless360 has a detailed video on this . The takeoff bearing is fixed upon GPS lock .
To me that is synonymous with initializing the IMI since they happen together upon startup .

Thanks for the clarification. I noticed this I need to point the plane to the north if not use a compass during startup. If not, the heading degree will not be correct.

Does this suggest set up a takeoff waypoint is better than using takeoff mode? at least the plane knows the takeoff wp is the target direction.

… are you talking ArduPilot there? Link to video if so.

Thanks for the clarification. I noticed this I need to point plane to north if not use compass during start up.

… what difference do you see based on the plane’s initial yaw value?

Does this suggest set up a takeoff waypoint is better than using takeoff mode? at least the plane knows the takeoff wp is the target direction.

There’s less that can go wrong with a takeoff wp - but its far less
convenient than takeoff mode. We do a chunk of work to try to deal with
bad headings in takeoff mode.

1 Like

The difference I noticed is before taking off.

The different is the delta between north and the direction the plane point to when power up.

For example, if the plane is pointed to east during powering up, there is 90 degree delta between the plane pointing and real direction when rotating plane before taking off. I think this is due to the initial degree is zero when powering up without a compass.

That’s why I point the plane to north when plug in battery. Not sure if I need to do this or not. I think the arduplane will learn the direction from gps track when moving enough distance.

That’s not right. You need to sort out that compass.

Yes. I solved this by pointing the plane to north when power up. There is no delta if I do this.

I noticed the case in the example if I didn’t point the plane north before.

There is no compass on my wing. I disabled it due to mag interference.

Then I suggest you stop using auto-take off. Or fix the compass. AFAIK Auto-take off needs the compass for the heading at slow speed.

Hi Alister,

This is not true. I have performed a 3 digit number (more than 100) of successful “Auto Take off’s” on different ArduPlane versions from 3.9.4 up to 4.0.6 without the need of a compass.

Normally the EKF performs a Yaw alignment after achieving sufficient speed (greather than 5m/s AFAIK).

The usual messages of a typical “Auto Take Off” are shown below.
The status message of the EKF yaw alignment is shown bold.

MAV>
2020-10-17 17:43:49 ArduPlane V4.0.5 (0bfa2638)
2020-10-17 17:43:49 ChibiOS: d4fce84e
2020-10-17 17:43:49 omnibusf4pro 00330042 3137470B 30363730
2020-10-17 17:43:49 Param space used: 1920/9728
2020-10-17 17:43:49 RC Protocol: SBUS
2020-10-17 17:43:49 New mission
2020-10-17 17:43:49 New rally
2020-10-17 17:43:49 GPS 1: detected as u-blox at 115200 baud
2020-10-17 17:43:49 u-blox 1 HW: 00080000 SW: ROM CORE 3.01 (107888)
2020-10-17 17:44:01 Mission: 1 Takeoff
2020-10-17 17:44:01 Resetting previous waypoint
2020-10-17 17:44:04 Armed AUTO, xaccel = 5.9 m/s/s, waiting 0.0 sec
2020-10-17 17:44:04 Triggered AUTO. GPS speed = 0.1
2020-10-17 17:44:07 EKF2 IMU0 yaw aligned to GPS velocity
2020-10-17 17:44:07 EKF2 IMU0 is using GPS
2020-10-17 17:44:09 Holding course 18505 at 15.2m/s (-8.8)
2020-10-17 17:44:10 Takeoff level-off starting at 9m
2020-10-17 17:44:11 Takeoff complete at 22.72m

Using a compass (on a conventional plane) can make the ground handling before takeoff a lot easier.

Regards.

As a married man I’m used to be wrong. :slight_smile:

I see you are using auto-take off as part of a waypoint mission. Have you also been successful using auto-take off mode without a compass?

Thanks!