Spiral of Death--Compass issues in Auto Mode

Log Analysis -- deprecated Copter Logs -- deprecated
1

My goal has been to create fully autonomous miniquads. Because of the close proximity of all the equipment, the main challenge is preventing interference of all the components. I am progressing in figuring the sources of interference and designing proper shielding.

I have attached logs which show a quadcopter on an autonomous mission about 500m long. I begin each mission in stabilise, then a bit of flight, then switch into Loiter prior to activating Auto mode. If loiter looks good, only then do I activate the Mission.

On the fights, the compass offsets suddenly go haywire at a certain point on the mission.
[size=85](note: it might coincide with my transmitter throttle failsafe, which is set to “Continue with Mission (Auto)”.)[/size]

I am careful in always calibrating the compass (all offsets less than 100) and have done the CompassMot procedure (many times–generally max offset is about 29%).

Attached is a picture of Droid Planner, showing where the craft enters the “spiral of death”.

[attachment=1]magErrorAPM.jpg[/attachment]

And the KMZ from the logs.
[attachment=0]Screen Shot 2014-10-11 at 11.37.04 am.jpg[/attachment]

Note: for this flight I set Compass_Learn to 1, and WP_Yaw_Behaviour to 0, but I did three other flights where the mag offsets suddenly caused a problem with Compass_Learn at 0, and WP_Yaw_Behaviour to 2.

I do see that there are some issues with my compass interference, but am confused as to why the mission starts off well then goes haywire at a certain point.

Logs for four flights are here: deuce4.net/web/APMlogs.zip

In general, after browsing many forums, there seems to be an unresolved issue with what is sometimes called the “death spiral” in loiter and auto modes. It clear that it is caused by compass magnetic issues, but I wonder if the code could be modified to make the response more robust. The death spiral appears to me as a fight between the altitude PID (trying to regain altitude, and sending more power to motors), and the roll/pitch/yaw (trying to move to the designated GPS point). Once it gets into the spiral, it continues. It seems to me the code could recognise this spiral, and switch into stabilise, or somehow recover from the death spiral. I originally posted this as a possible issue at github.com/diydrones/ardupilot/issues/1474 . There I got some excellent analysis from jschall, who identified that I had yaw error, but I still don’t understand how the quad initially flies well in loiter or auto, and only part way through the mission enters the spiral of death.

2

Compass error can depend on the orientation of the aircraft. For example, if you have a huge X axis offset, and the X axis is facing north, you could be perfectly correct.

If you have a well-calibrated compass that is not subject to interference problems from the motors, you can thrash the copter around all you want at any orientation and never have an issue.

That said, the EKF in version 3.2 on PIXHAWK will both use the compass more intelligently and observe yaw during maneuvering more intelligently.

I don’t know where all this “death spiral” stuff is coming from. It is not a systemic problem with the software, it is just the most common way users fail to set up the autopilot properly, and we’re working on that. That cure is most likely going to be PIXHAWK-only, however, and that is because we’re out of everything on APM2. CPU, RAM, code space.

In the meantime, why don’t we focus on your specific problem instead of deflecting it onto the project as a whole.

First, turn COMPASS_LEARN off. It causes issues on copters, especially ones with bad interference.

Second, please send a tlog or dataflash log in which you rotate the copter as in a compass calibration. That means, point each axis of the copter up and down, and do one full rotation about that axis. So, copter upright, one full rotation, copter upside down, one full rotation, copter nose down, one full rotation, copter nose up, one full rotation, copter left side down, one full rotation, copter right side down, one full rotation. The order doesn’t matter.

Third, please redo compassmot. Throttle up to your typical cruise throttle (seems to be 55%ish) but DON’T let the copter move during the compassmot. Ziptie it to something if you must, or reverse the props (put the CCW props where the CW props are and flip all of them upside down) and set it on a hard surface. Throttle up and down repeatedly, until the numbers seem to settle or 10 times. If possible, connect or configure a power module to measure current for compassmot. Current is much better correlated to magnetic field, throttle just kind of works in a pinch.

3

Thank you JShall, much appreciated.

Are you saying that at some point in the flight, the yaw changed (either by wind or programatically by the mission), which caused an already existing large magnetic offset to become a actual problem and cause the spiral? I was thinking along the same lines, but generally I yaw around in Loiter prior to switching to Auto, to make sure it works in various compass directions–so I’m still a bit perplexed by the sudden onset of the spiral.

I’ll look into how to get tlogs of compass calibration, and redo CompassMot. I don’t generally fly with Compass_Learn–just set that on last flight (along with WP_Yaw to 0) to see if that helped (the prior flights had similar problems with Compass_Learn off).

I think my bigger problem is how to pack all the stuff (APM, 3DR radio, GPS and compass, RX, VTx, etc) into a small frame and prevent interference among the components. One line of thought is that I should perhaps use the internal compass and calibrate carefully with CompassMot, as no matter where I put the external compass on a small frame, it will be close to compass interference sources, and I think I am getting more variable results with the external compass (photo of my current build–when I move GPS and compass further up front, I get GPS interference from the camera; right now my compass interference comes from being close to the current flow of the battery, I reckon).
[attachment=0]IMG_4711.jpg[/attachment]

I didn’t mean to infer that the code had problems, just was thinking that there might be a way to recognise bad compass offsets in-flight, and not spiral and crash in these types of situations–in other words, a possible code feature.

I am very much looking forward to 3.2 (any word when the public release will be?) and building a quad with my new Pixhawk. In the meantime, I would like to get the APM working properly, as I still have a few APM’s that are looking for builds :slight_smile:

4

3.2 will be very soon. You could simply make your compass tower taller. Get a 3dr compass tower, they fold.