I wanted to start a conversation around the roll and pitch of Arducopter drifting as you fly.


The reason is I just assembled new hardware and problems that weren't there before have now shown up in a bad way. Flying indoors in a 5ft space I was able to get up to 30° error in roll and around 10-15° in pitch. I was able to control it and it flew perfectly level the whole time, I just had to hold the stick into the corner of the radio. Lading and waiting corrects the issue.


What could cause this. I had been flying an older version of the IMU this whole time. This version has an analogue filter for the gyros where the new hardware has it as an option. You must solder the pads around the gyros to enable them. I was also flying with two slightly tweaked motors giving off a lot of vibration. This could affect the accels. 


My question is: If you have a problem like this, what is the vibration level on your copter, and do you have the filter pads soldered? 


And notice I didn't say "loss of control" or "it didn't fly stable". I had control, and it flew perfectly. It just lost it's reference to the ground and I had to compensate with the stick. Had it been worse than 45° I would have lost control. 

There are three pairs of pads, each with a white outline. (look for GYRO-XY near the relay).

Jani Solders his to enable the filter. I have never flown this board until now. I will solder them to test the filters this week.


Views: 5260

Replies are closed for this discussion.

Replies to This Discussion

Thank you Olivier.


Here are the results.. As we can see the 800Hz spike is there also. The noise pattern is otherwise very good.

The interferance is stronger with 4 motors, which is as expected. Can you also collect the acc_x (channel 4) for me?


How is your copter is it one of the "good ones" or the "bad ones"? :)


As usual click the images to see the animation.

First 1 motor:

Then the 4 motors:



I suspect acoustic coupling of the APM / IMU board.


Could you try fully separating the motor from the APM / IMU board, (mount it on a isolated arm you could hold in your hand) but keeping approximately the same distance between motor and APM board ?


If there is acoustic coupling through the air, then you should get the same noise at 800 Hz.



Did that yesterday, then I held the motor next to the gyro. Now I held the motor (on a rod) approximately at the same distance from the APM as it would normally be attached.

Same result. Flat spectrum, i.e. it is not acoustic coupling.

Tried also the silicon tube attachment of the APM. It reduced the 800Hz spikes somewhat.

I can not see the the 800Hz disturbance on the ADC line from the Gyro, the VREF of ADC or on VCC measured at the ADC.

It occurred to me 800 Hz might be a natural frequency of the arms. If you try clamping a weight in the centre of the motor arm being used and see if it moves the 800 Hz spike, and then repeat clamping it at the end near the motor.

It could be a torsional mode, so a wide weight that resists arm rotation would be another test.  If the spike doesn't move in any of these cases, then that eliminates that.



This is very strange.


Eventually the disturbance could be an harmonic at many times the sampling frequency. This could explain why you don't see it on the analog output.


Or there is a problem with the sampling clock. But again you did check that and it seems ok.


I've checked the IMU board schematics, it seems that the gyro and accelerometers signals are sampled by an ADS7844 sampling / multiplexer device. The main AVR is responsible to send the sampling clock (PH2 AVR pin).


Strangely, on the APM 1280 schematics, the PH2 signal is marked "NA".


Could you check the clock signal on pin 19 of the ADS7844 ? Must be 16 times the desired sampling frequency.






Rob, if it was a modal frequency resonnance of the arms, then this should be seen on the analog gyro outputs.


if the frequency, or an aliased harmonic is not present on the gyro analog output, then there is another problem somewhere.


The sampling chain needs to be checked from the analog input on the ADS7844, to the AVR input, and the sampling clock needs to be checked as well.


I ask myself if there would not be an error on the sampling clock frequency. It must be 16 times the desired clock, because the ADS7844 is a multiplexer sampler.


Maybe you've solved this later on, I didn't read the whole post. IMHO the kind of crash filmed happens when a motor gets loose (I've had 3 of those before I noticed, luckily not much has been destroyed). Of course I might be wrong, but possibly there is no relation between the drift issues in question and the weird crash.

Thank you very much Kári.


This is a good news for me as I did not expect such good results.

I do not know if my frame is good or bad one, but I did not do anything special except using small grommet (the one from small servo) to attach the APM. Maybe it is enough to filter "high frequency".

But one must not forget that the propellers are removed.


Here is data from acc_x (1 motor). I modified the following line by replacing 1 with 4 like this :

data[cnt].data = (uint16_t)adc.Ch2( 4, &data[cnt].cnt );

Is it OK ?




Thanks oliver.

By bad copter I just meant a copter with the undesirable YAW behavior.

Yes this is correct code change. I will analyse the data in a bit.


Ah OK. So, I do not have undesirable yaw behavior. I had when compass declaration in the code was wrong, components down while it was components up.

I only suffer drift after "aggressive flight", like fast forward/backward, the copter drifted more and more to the right/back, then I have to land and switch off/on before loosing control.

I will try revision 2.0.24 this week-end.


I had some error/bug in my analyzing scripts (duhh) . I have those fixed now and I am writing up a short summary, with "correct" analysis I will post all scripts and data for you guys to analyze and criticize.

Although the error in my scripts was making me focus on some non-existing weirdness the basic assumption I started working from was correct, i.e. there is aliasing in the data which as far as I can see will cause problem with all of the ADC channels.

I started a fresh forum thread with this analysis.


© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service