Multicopter can't fly straight after a launch. Position slides sideways

Thank you for your time.

It’s mounted perfectly straight forward, not tilted or anything else. It’s mounting error is within a one degree.

I will have to give that a try.

I will do that motor calibration later to be sure it’s not interference. But by looking several logs, I’m not able to see any severe interference on the magnetometer. I don’t see that motor outputs (current) would affect magnetometer. I’m only seeing differences on lifting up out off ground and doing normal maneuvers. The wiring is designed, so that it has minimal magnetic field and is not routed next to important sensors. The high current wires are twisted.

On this image I have plotted the primary magnetometers X,Y,Z axes and RMS of total magnetic fields and throttle output.

There seems to be no severe changes on the magnetometer data. In my opinion this looks normal data. Magnetometer values changes slowly when lifting off the ground, which is normal. Throttle output doesn’t seems to affect the “total” RMS value.

You are correct that it does state its only affecting if its saved or not. That compass_learn “2” is more preferred learning method, if EKF has normally good quality estimations. The “1” setting “internal-learning” is not clear to me either.

I had a quick look at the logs.

In general the slight turn indicates that the actual heading is not what the compass is indicating. Because it seems the problem goes away after a few maneuvers, this indicates that the EKF is able to use the GPS movement to get the heading to the correct value.

So as for the cause of the problem… there doesn’t seem to be much interference from the motors on the compass. This is clear from looking at the length of the vector (sqrt(sq(MAG.x)+sq(MAG.y)+sq(Mag.Z)) vs the throttle (CTUN.ThO) and the length of the vector doesn’t change hardly at all during the flight. In general it doesn’t look like interference. This means that compassmot won’t help.

If we graph the compass heading there are quite a few times where it is very far from the EKF estimate although I suspect the mission planner is not correct adjusting the heading based on the vehicle’s attitude.

I can imagine a few possible causes:

  • the automatically looked-up declination (COMPASS_DEC = 0.172rad = about 10 deg) is not correct. Manually updating the declination could fix this although I don’t know of any cases in the past where this has helped.
  • the compass on the vehicle is not perfectly pointing forward
  • some kind of issue with the EKF. only @priseborough could perhaps give some advice

Thanks for the comprehensive reply @rmackay9.

Automatically looked-up declination is almost as correct as it can be as the local declination is 9°55’ = 0.173rad. Local declination is checked from
I probably should fly somewhere else to see if the behavior changes. This could rule out the possibility of some local magnetic phenomena or difference from the declination.

I have already manually tried to adjust the compass module “heading” to see if this is the case. I went trough +/- 5° with about 0.5° steps and re-calibrated compass and it didn’t get any better from the default 0° position. The behavior either stayed the same (no significant improvement) or got worse. These results were only evaluated visually. I believe that I could not see any significant improvement from the logs either.

Do you see a crabbing effect in Auto missions or Loiter ?
when the drone path is straight to the target ,and in the MP the heading is right to the target, The actual heading ( what you see when you look at the drone ) , has offset to the side , such the drone heading will be offside to the direction of flight ?

Hi, @VDLJu @priseborough @rmackay9 Have you solved this problem, as I have faced the similar problem. I am very appreciate that you can give me some ideas to solved this problem.

This is my log here log file.

Now when I switch to the loiter mode, it can not go straight。

and i found that the magnetic length is

I have not resolved the issue, but I have a feeling that this could be caused by IMU yaw offset. I haven’t found any code regarding IMU yaw rotation calibration. Only Pitch and Roll is “trimmed”.

@priseborough @rmackay9, how does ardupilot solve the IMU yaw (rotational) offset?.

I have created other post which is related to this issue. IMU yaw orientation aligment?

If it is possible, could you please add my wechat huangwenfuture or my e-mail and share the log to me, maybe i can give some help. I have solved this issue Copter can not go straight in Loiter mode . (I can not get the google web as in China)

Hello @huangwen0907,

I haven’t had any issues with compass due motor/current interference. I have done multiple tests with maximum loads and still the external compass doesn’t show any interference. The cabling is made with minimizing compass issues in mind and the external compass is quite far away from interferers.

I strongly believe that this issue is due some other than compass. I haven’t found any reason why it couldn’t be that IMU YAW (rotational) offset from the drone body heading. Also, this issue goes away after flying a while. I believe that EKF compensates this error.

Could some one look in to this log, if they see something that could be the cause.
Google Drive link to log

I have had randomly the same issue (copter not going straight) and recover after few minutes. Maybe some devs can come in and take a look at why it does it.

It is very easy to find out if it is compass related.
Fly in alt-hold mode. If it flies straight in alt hold then it is definitely a compass problem.

Ok, will try that, thanks for the hint.


@Eosbandi @anon67614380
For me this only happens when using GPS assisted mode (Loiter mode). So it is most likely a compass related issue?

I haven’t solved the issue yet.
Things tried so far that didn’t help:

  • Recalibrating compasses numerous times with no visible interferers close by.
  • Changed to a new GPS/Compass unit (Here2).

Things that have had effect on some degree:

  • Manually adjusting the compass yaw axis by rotating it relative to frame. This minimizes the original issue after the take-off for a short time, but after that the drone is very susceptible to toilet-bowling while doing quick 180+ degree rotations (+90deg/s).

I have this same problem on all our Drones that we manufacture.

Drone moves off straight line and leans to left.

After a bit of flying around it corrects itself, but on restart it is back to same problem immediately after take off with first forward flight.
Can you help?

Although data above showed that magnetometer is giving pretty much correct values, the problem was solved with improving the compass calibration procedure to have more consistent measurements and better elliptical calibration. The error on compass calibration values doesn’t need to be much off to have this issue.

Hi All

I attache the log file of a flight to show the problem.

I will also do a log with another drone to check the problem replication.

.As discussed, on the first forward flight, the drone will lean to one side in forward flight. After a few turns, then it will be able to fly straight properly. Very annoying especially for a beginner.

Im just tryin to to establishg the cause, so that I can at least give my customers some good feedback and solve the problem.

I hope someone can help.



2020-03-31 12-28-10.bin (2.37 MB)

2020-03-31 12-33-35.tlog (4.3 MB)

(Attachment 2020-03-31 12-28-10.log is missing)

Here is a second flight with a different quad.

What I can see is a high mag change in the auto analysis.

2020-03-31 13-16-34.bin (1.3 MB)

Hi All

Now let me explain why I am so frustrated with the ARDUCOPTER system.

I take exactly the same drone, but I put a TAROT ZYX-M gps system into it.

In exactly the same location I do a GPS calibration.

And every time the TAROT ZYX will control the drone in a perfect straight line with no problems. Fantastic.

We moved our component selection to use arducopter, so that we can give our clients more telemetry data whilst flying etc, but so far I am just struggling with getting the drones to fly properly with ARDUCOPTER.

Has anyone here every flown with a TAROT GPS system? or anything similar to a DJI phantom?

The gps mode is rock solid and drone behaves very well compared to that of the LOITER or pos hold in Arducopter.

The atti mode behaves much the same as alt hold in arducpter. In fact ALT hold in ARDUCOPER is very good I think in terms of how it has good control and stability.

I have spent months and hours trying to decipher problems with the drone using Arducopter. Very frustrating,

I really want to get arducopter to work as well as the TAROT GPS system.

All help will be appreciated.



Checked your logs.

You have issues with either with your build causing interference or you have bad compass calibration or both. Can’t say more.

1 Like

Arducopter 3.5.x was a bit sensitive to compass variations, although work had started on making it more bullet proof.
Encountered this a few times where initially after a compass calibration we would get yaw discrepancies that really messed with guided flight behaviour.

I would suggest the first step would be to update to 4.0.3 as a FRESH install, although it will install over your 3.5 OK I have always found it best to go back to square one when there is issues.
Do all the calibrations, follow the new Tuning Wiki and change appropriate parameters, then autotune, and if there is any yaw inconsistency calibrate compass again.

You also have front/back inconsistencies in RCout which is going to mess up pitch behaviour.

Have you balanced this copter?

You can also see inconsistent pitch behaviour in the desired/Actual even though the yaw is very tight.

Just some minor points that we have had to work out in the past.
I understand your frustration but Arducopter is still the most versatile and configurable autopilot out there although the learning curve can be a bit daunting sometimes

Thanks for Valued input.
We changed to Pixhawk 4 by Holybro.
We still have this issue.
I’m thinking it is vibration related.
I’ll send a new log.