I have been working on an improved altitude estimator for a while here but have been having issues with implementation.
The theory works fine but as seen above in the FFT of the accelerometer data, there is a significant ammount of vibration/noise in the sub 50Hz range. This is due to out of balance props etc. Needless to say, this proves to be very detrimental to estimating altitude and velocity changes when these vibrations are an order of magnitude greater than the actual accelerations felt by climbing and descending. You cant really low pass filter or band pass filter this because you need everything below 60 Hz or so.
So here is what I need from you guys:
Flight data that includes the following:
- dt in ms between samples
- phi,theta,psi
- barometric altitude
- sonar altitude (if available)
- ax,ay,az
make sure you notate units etc. The more information on the data the better. Thanks for the help and I will post the results. I'm really hoping to get some data from guys with slick clean vibe free quads.
Thanks
Beall
Comments
back on track - the mini flies.
but - way too heavy: 384 gramm.
now can i look how to get the flightdata after the neccessary diet...
aua - i just fried my one of motor outputs ...
need to modifiy the code that channel 6 acts like channel 1.
revision 1.4 of the mega board is required when using turnigy plush esc's!
maybe - maybe ... i get it working
one esc died - i have to wait until i have the replacement in.
then i can collect some data - if it flies :)
At the beginning of this thread I mention how to capture some data with ArduCopterNG..there were some mistakes in that.
For #1 - this line is fine if you're using the version of ArduCopterNG from subversion (not from download area)
Log_Write_Sensor(AN[0], AN[1], AN[2], AN[3], AN[4], AN[5], press_baro_altitude);but if you're using the download version you need to use this line:
Log_Write_Sensor(AN[0], AN[1], AN[2], AN[3], AN[4], AN[5], press_altitude);
Also for #2, this line:
Log_Write_Attitude(roll,pitch,yaw);
should be changed to:
Log_Write_Attitude(ToDeg(roll),ToDeg(pitch),ToDeg(yaw));
Can someone verify for me the size of the capacitors C10, C11 and C12 in the oilpan?
they should be 0.1uF resulting in 50Hz bandwidth of the accelerometer data, but I am seeing much
larger bandwidth. Is it possible that 0.01uF was placed instead, this would mean 500Hz bandwidth.
I used Octave only for plotting, yes and defining the filter,
octave : [b a] = butter(1, 40/800 );
Rest was done in the examples folder for the AP_ADC library :).
Do you want the plotting commands?
I will make a patch for the filtering in the AP_ADC library. But I wanted to fly the thing with that code before pushing it to the rest of the world. There is still a change that this does not work in the Time domain, though it looks good in the frequency domain :).
Can't sleep so I just keep on going.
Next step I analyse the raw 800Hz sampled data (blue trace), which we see is very spiky in the higher frequency range of the data. Spikes at 150Hz, 180Hz, 270Hz, 360Hz and 380hz in the top graph in image below. After going through the very simple averaging stage we see that the spiky noise is spread all over the frequency range (red trace) and after downsampling this would mean bad aliasing effect.
In the lower graph we see an alternative downsampling filter, i.e. the simple 1st order Butterworth (two multiplications, 2 additions, 1 shift, integer calculations) with -3db point at 40Hz (red trace in lower graph in image below). Still there is spiky residue in the upper frequency range but overall the filtered data looks much better. My guess is that a second order filter would take care of this leftover in the upper half of the frequency range.
Y - axis is now logarithmic in order to better see the effect of the filtering (red traces). X-axis is correct now, i.e. base sampling is running at 800Hz and we are looking at the raw data. 800Hz is two times the normal sampling in the current arducopter code.
Spikes are not in the same place (blue traces) on both graphs, thats because motors ware running at diffrent speed between these two measurements.
So why is the first red trace (downsampling filter as distributed by arducopter) behaving so badly? I think (have not analysed data yet) that it is because the history in the filter is thrown away every 50 hz, the sampling rate of the downsampling stage, i.e. instead of defining a delay line of say 400/50 = 10 samples ( or 800/50 = 20 samples for my test setup) and calculate a running average for every sample the delay line collects those 10 samples by accumulation and when the data is read by the downsampling stage the history is flushed, i.e. we start from zero again. Therefor the inherent connection between samples is forgotten every 50 Hz. This is exactly what we see above, i.e. bad aliasing with 25Hz images spread over the whole bandwidth. We can think of it also that we are getting a filter step-response every 50Hz.
Argh.. The x axis shows the wrong frequency. It sould be showing 0Hz-25 Hz. The base sampling is running at 800Hz while the downsampler takes it down to 50Hz, i.e. the bandwith is 25Hz. Same goes for the former picture. There the base sampling is running at 390Hz and 425Hz but downsampler is the same running at 50Hz so the bandwidth there is also 25Hz on both pictures.
Sorry for the confusion.
Further analysis. I raised the sampling rate to 800Hz (measured on oscilloscope). I also raised the SPI clock to 8Mhz which I don't think is relevant for this analysis but that is the setup used for the analysis. I then the recorded for few seconds where I increased the motor speed, 1300, 1400, 1450, 1500 and 1600, 1500 is half throttle. This is with no propellers. As we can see from the following picture we have aliasing. We can see how the disturbance spike goes up in frequency when the speed is increased for the first two pictures, then it starts to move downwards in frequency for the next three pictures. I did not bother scaling the y-axis. The x-axis shows frequency.
-
1
-
2
-
3
-
4
of 4 Next