Drift Issues - Aliasing

This is a followup to the aliasing discussion in http://diydrones.com/forum/topics/arducopter-drift-issues

Here is a short summary of the analysis done by us regarding the aliasing possibility.

Same as before click on the images below to get the animation if it is not showing directly in the thread.

This data is collected with two copters, one built by me. Using circurlar 10mm aluminium tubing for the arms. And older version of the Oilpan, Foxtrap 2.2. Olivier was so kind to send be some data from a official Arducopter frame with square tubing for the arms and new Hotel Oilpan, with the lowpass filters enabled for the Gyros.


On the images you will see two vertical magenta lines, These are estimate of the rotational speed of the motor in HZ. They ware measured on my particular motors (BL 2217/9) with fresh 3 cell lipo batteries. So they will not be exactly positioned correctly with the big disturbance spikes in the FFT which was measured with not so fresh batteries. This is especially true for the data I got from Olivier which has different motors than me.


Also on the images you see two red vertical lines. Those lines denote approximate bandwidth of the down sampled data. The main loop, should run at 200Hz, which means bandwidth of 100Hz maximum. I draw the red vertical lines at 80Hz.


All the images show FFT of data sampled from the yaw gyro or the x axis on the accelerometer. These are channels 0 and 4 respectively on the ADC. We can see that the disturbance power follows the rotational speed of the motors which are the main source of vibration. 


You can see that the data on the first two pictures on my quadcoter the 2nd overtone of the base frequency is passed easilly thought the quadcopter structure. I am using circular tubing for the quadcopter arms. This indicates a non optimal frame. This is not the case for Olivier's quadcopter which is the official Arducopter frame with square arms.


As you can see in the animation then the vibration disturbance very soon moves out of the 80Hz bandwidth of the main loop. This means that all data beyond the 80Hz will be aliased down to the band of the main loop where it will look like slower rotation/gravity signal depending on the channel.

But it also means that with proper signal processing and or analog filtering most of the vibrational disturbances can be gotten rid of. Making the life of the DCM and control much easier.


The accelerometer data (last animation below) has also indication that there is aliasing of data from above 1000Hz. It is hard to prove though since the APM is getting close to it's limits with the 2000Hz sampling used for creating these images. To prove or disprove higher sampling of 4000Hz+ would be needed.


I am not sure about the filtering bandwidth of the DCM. It has surely norrower bandwidht than 80-100Hz so in many cases where the aliasing is not to bad the DCM will successfully reject the disturbance. But as soon as the aliasing gets worse, i.e. the disturbance noise gets closer to 160Hz the DCM will not be able to distinguish between the aliased disturbance and the normal fluctation of the gyro because of movement of the quadcopter. Making the motors rotate faster or slower will move the aliased disturbance in and out of the working bandwidth of the DCM.


The two two animations measured on my quadcopter are different in the lowpass filter bandwidht on the Oilpan. In the second image I soldered 3.3uF capacitor in parallel, which should give 62Hz bandwidth of the analog signal. This does not seem to work. I am still looking for a good reason for that. There is also an internal lp filter in the gyro with bandwidth of 140Hz. But as can be clearly seen from all the images that there is a lot of energy in the band above 140Hz.


In theory there are possible ways to fix this on the digital side but because of how close the disturbance is to the usable data these require some serious oversampling, i.e. the digital filters have to be quite sharp. 


Attaches is a zip file with all the data and the script to generate the images. Hopefully some of you can find a bug in the script and prove me wrong.


First image is my copter with standard 0.1uF capacitor. Oilpan is older Foxtrap 2.2.

Channel is channels 0 the yaw gyro.




Second image is my copter with large 3.4uF capacitor.

Channel is channel 0 the yaw channel.


Third image is sampled from  Olivier's copter, Arducopter frame, Hotel Oilpan with capacitors activated.

Channel is channel 0 the yaw gyro channel.

3690873599?profile=originalForth and final image is also from Olivier's copter. 

Channel is channel 4 the x-axis acellerometer.


You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –


  • Ah, thanks JMD45 for the insight! Yes, it seems one must look into how big a chip we'd need and the licencing on the IP's and such to keep it reasonably open source and low cost.


    Actually, there has already been folks doing just this! Today I read about the Papillio One and the Alien Cortex:





    They both seem pretty Arduino oriented-ish. Both seem to be able to run AVR cores, to emulate AVR and using them straight in the Arduino IDE it seems! I saw they even mentioned running 4 AVR's in the same FPGA, Spartan 3E because Xilinx apparently had some free development tools available. That Alien Cortex had also incorporated some ADC units and such to be more Arduino/AVR compatible. 


    The disadvantage of those boards might be size, but that's easily remedied if someone would just make one with similar hardware only suited more to our goal, for flight controller board in a very small footprint. Hell, even I am interested in designing the hardware for it! That would allow for 100% freedom which would be awesome!


    Chips don't seem to cost much either, 10-17 USD! http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&nam...

    So the idea is definitely feasible! Especially with the possible software support from those other mentioned projects. And there's probably other emulated cores than the AVR's too, there must been someone who did a Cortex/ARM 32-bit core too I imagine.

  • Hello there. Read everything in this thread and the initial thread about the yaw drift problem where you seem to have started this analysis.

    Very interesting reading and results indeed! Great job!

    I started out reading here to know what to expect, then I went measuring too on the Oilpan, more specifically on the Z/X outputs of the accelerometer since that is our biggest problem. I used digital spectrum analyzer with 102kHz bandwidth, but after 1kHz there seems to be very little signal at all anyways.

    My results were after the 50Hz LP filter on the accel signals, and by judging from what I got, after the 50Hz RC filter, the amplitudes/energy in the 100, 200, 300 and 4-450Hz regions was about the same. This means that without the 50Hz RC filter in place, we do have increasing amplitude after 100Hz, so the 400Hz component is for example greater. At least in my test frame which I was holding in my right hand during the tests, simulating real flight as much as possible.

    I saw your comments on digital sensors... I say clearly no, at least to the digital sensors I know of. They often seem to be developed to handheld devices for gaming and such, but not suited to vibrating environments so much, thus not including more than simple internal RC filters of the first order. Clearly we need higher order filters which I intend to make a little design around, and therefore require analog sensors. In Aeroquad, where most currently use the BMA180/ITG3200 we also have aliasing troubles, but since they're purely digital (I2C) there's no good way of analyzing the frequencies coming through.

    Another approach is however to oversample like crazy, then only a simple RC filter is enough, but then you'd probably need to exchange the processor to handle the amount of data to be filtered in software instead, and I think that's not as slick a solution as filtering in the pre-ADC stage. I've read about someone sampling analog gyro's here at 30kHz with good results, but this again requires analog gyro's since those bandwidths seem much too high using external ADC's.

    Anyhow, this is a vid of my analysis (don't have a 3.5" floppy in the computer anymore :) And no GPIB port either...)

    And here's the thread on AQ where I wrote more about it:

    Hope it helps!
  • Developer

    Hi Kari,

    to add a bit more data to this thread, here there are some views of an FFT that I did with a digital oscilloscope on the accels and gyros analog signals (standard board)

    First graphs are from the X accel and the last one is from a gyro channel. Blue and green lines are 500Hz and 1000Hz.

    I was using a sampling rate of 20Khz and the test was made on a high vibration test bench


    I am making some more tests on this and trying to improve the ADC_lib to solve the aliasing problems on actual boards. Clearly the accels have more bandwidth so we could play increasing the sampling rate of accels only (twice than gyros)... I will try to post more info on this...



  • Got all the components and inserted one filter in the z gyro channel, channel 0.

    The effect is quite noticeable.  Compare the first animation in the original post to the new animation here.

    Note the scale is little different.  Side lopes outside of the 80Hz mark (magenta lines) have disappeared.

    The filter seem to add some DC bias, but that is removable e.g. with calibration.

    The plan is to connect filters on all gyro and accelerometer channels.

    Accelerometers (the more interesting case) will be a little difficult since there are no series components on those channels, so lifting legs on the ADC is necessary.


    The filter is Maxim 7410EUA, with 3300pf filter which defines the -3dB point at 90 Hz.


    Attached is zip file with dataset and octave script to generate the data.

    3692234815?profile=originalMore later.


  • Here are some interesting results for the accelerometers. I am using ch4 in these images but they all (4,5, and 6) behave the same way. All the data is sampled at 4000Hz, one channel at a time.

    So in the first animation and picture is the behavior if the capacitor is removed. Here we can see that the accelerometers are really sensitive beasts. Note the different Y axis scale.


    The second animation and image are for the standar 100nF capacitor which should give us 50Hz bandwidth.

    The third set is for 470nF capacitor which should give 10Hz bandwidth. The filtering is obvious but the effect is

    far from being powerful enough. Remember that the red vertical lines are at the 80Hz marks.


    Basically the assumption has to be that the vibration sensitivity so high that the disturbance is basically breaking up

    through the stop band of the filter.  Next I have to find/buy/build some higher order analog filters and see how effective they are.


    Attached is the dataset, octave script to generate the images in the animation and the code to measure the data.


    First the data with no caps. First the FFT


    Then the time series.3692228634?profile=original

    The data for 100nF caps. First the FFT

    3692228563?profile=originalThen the corresponding timeseries.


    Finally the 470 caps modification. First the FFT

    3692228694?profile=originaland the time series.




  • Interesting links JMD45.

    Just a quick note. The reason why there is no difference between pictures 1 and 2 above, is that I accidentally overwrote my data file with data from another channel.

    The capacitor does have effect on the bandwidth as is to be excepted.
  • Developer


    I've just found those informations. Could be usefull to some of us with vibration problems or just to check.


    It is particularly interesting to see that sometimes an unbalanced propeler can compensate for an unbalanced motor if it is mounted with the right angular offset.










  • 3D Robotics
    Impressive work and explanation! We'd like to bring you in to some of the discussions of future hardware and sensor choices. Please PM me so I can connect you with the right people.
This reply was deleted.


gotham liked gotham's profile
15 hours ago
DIY Robocars via Twitter
RT @RoboticMasters: Monaco GP Circuit in the Donkey Sim (coming soon). Including buildings, tunnel and all! https://github.com/robotics-masters/sim-donkeycar-f1/tree/f1-tracks @diyr…
DIY Robocars via Twitter
RT @breadcentric: Here are the details of #AWSDeepRacer finals: https://blog.deepracing.io/2020/12/01/aws-deepracer-league-finals-2020-round-1-schedule/ #awsreinvent2020 #AWSreInvent https://t.co/ovqsjp8V…
DIY Robocars via Twitter
RT @breadcentric: #AWSDeepRacer League #awsreinvent2020 Open race is on Dec 1st - Dec 31st in three categories, 15 DeepRacer Evo (with LIDA…
DIY Robocars via Twitter
RT @a1k0n: @SmallpixelCar @diyrobocars It's just something that's easy to track with chroma keying. I ended up using different colors on th…
DIY Robocars via Twitter
DIY Robocars via Twitter
RT @TinkerGen_: "The Tinkergen MARK ($199) is my new favorite starter robocar. It’s got everything — computer vision, deep learning, sensor…
Nov 23
DIY Robocars via Twitter
Nov 23
DIY Robocars via Twitter
RT @roboton_io: Join our FREE Sumo Competition 🤖🏆 👉 https://roboton.io/ranking/vsc2020 #sumo #robot #edtech #competition #games4ed https://t.co/WOx…
Nov 16
DIY Drones via Twitter
First impressions of Tinkergen MARK robocar https://ift.tt/36IeZHc
Nov 16
DIY Robocars via Twitter
Our review of the @TinkerGen_ MARK robocar, which is the best on the market right now https://diyrobocars.com/2020/11/15/first-impressions-of-tinkergen-mark-robocar/ https://t.co/ENIlU5SfZ2
Nov 15
DIY Robocars via Twitter
RT @Ingmar_Stapel: I have now explained the OpenBot project in great detail on my blog with 12 articles step by step. I hope you enjoy read…
Nov 15
DIY Robocars via Twitter
RT @DAVGtech: This is a must attend. Click the link, follow link to read the story, sign up. #chaos2020 #digitalconnection #digitalworld ht…
Nov 15
DIY Robocars via Twitter
RT @a1k0n: Got a new chassis for outdoor races (hobbyking Quantum Vandal) but I totally didn't expect that it might cause problems for my g…
Nov 11
DIY Drones via Twitter
First impressions of the Intel OpenBot https://ift.tt/36qkVV4
Nov 10
DIY Robocars via Twitter
Nov 9