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.
Channel is channel 4 the x-axis acellerometer.
I repost this just in case.
The corner frequency can be adjusted with a clock input : Fc = Fclock / 100. So it is possible to make dynamic adjustments.
Or it is possible to set a fixed Fc, with a simple external capacitor.
5th order is a good compromize between efficiency and stability / linearity.
For a better linearity from DC to Fc, butterworth is recommanded.
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.
Good work Kari.
This prouve that aliasing do occur without filter.
Maxim gives +/- 4 mV for DC bias. Is it the value you get ?
For futur hardware design, i think that it could be simpler to use digital output gyro / accelerometers (if they have a clean output), so that the cost can be kept as low as possible. Reliability would be certainly higher as well with digital outputs - no added components - no external bias and aliasing problem.
What are the results when flying ? Any improvements ?
Have not done extensive flying tests. But basically my suboptimal frame goes from unflyable mostly because of yaw issues to very flyable, almost stable.
I ordered an Arducopter frame and I am waiting for it to arrive (over two weeks now) so that I can compare performance.
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...
Adding coprocessors is a good idea, but in the end we'll a lot of chips on board.
I think that the best option would be to replace all processors and logic circuits with a small or medium FPGA, so that we can have as many dedicated filters and processors on a single chip to manage all what we need, from ppm encoding to gyro filtering and with lightning fast processing.
Another option is to add small AVRs, one for each gyro output, oversampling and FIR filtering each output. Or use a single small DSP.
True.. I was just thinking of a solution that will benefit all that allready have the apm and the oilpan.
The coprocessor board would mount inbetween the apm and oilpan. Making a three PCB sandwich and stealing the SPI port that goes to the ADC on the oilpan. That coprocessor board must be cheap I guess. How expensive are these FPGAs?
The long term solution redesigning everything has many options.
There are allready boards out there with much more processing power, e.g. Bill's board and Roberto Navoni's board. Roberto's board is oilpan compattible, while Bill's board uses different approach and uses only analog sensors. I guess Arduino will at some point offer 32bit solution and so on. I havn't checked if they are opensource though.