Replies to This Discussion

DeveloperPermalink Reply by Olivier ADLER on June 23, 2011 at 4:22am

 

I repost this just in case.

 

http://para.maxim-ic.com/en/search.mvp?fam=filt&274=1&588=5...

 

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.

• ▶ Reply

Permalink Reply by Kári Davíðsson on July 7, 2011 at 5:06pm

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.

More later.

Attachments:

• filter.zip, 684 KB

• ▶ Reply

DeveloperPermalink Reply by Olivier ADLER on July 8, 2011 at 12:29am

 

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.

• ▶ Reply

Permalink Reply by Kári Davíðsson on July 9, 2011 at 4:20pm

It is different between channels, but all withing +/-4mv.

Yes probably that is the way to go. For that type of gyro one must assume that they get the sampling stage correct, otherwise the device would be useless.

• ▶ Reply

Permalink Reply by Kári Davíðsson on July 9, 2011 at 4:35pm

And here is the acell channel wiht 5th order butternworth analog fitlter.

Compare to the data posted on June 22. earlier in this thread. Note the difference in scales.

 

Attached is a zip file with animations for all of the channels. Results basically same for all channels.

 

Attachments:

• filter 2.zip, 4.6 MB

• ▶ Reply

DeveloperPermalink Reply by Olivier ADLER on July 10, 2011 at 2:33am

 

What are the results when flying ? Any improvements ?

 

 

• ▶ Reply

Permalink Reply by Kári Davíðsson on July 10, 2011 at 3:31am

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. 

• ▶ Reply

DeveloperPermalink Reply by Jose Julio on July 11, 2011 at 8:12am

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...

 

Jose.

• ▶ Reply

Permalink Reply by Henrik Larsson on August 27, 2011 at 9:45pm

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...)
http://www.youtube.com/watch?v=R0zpwML1Dp8

And here's the thread on AQ where I wrote more about it:
http://aeroquad.com/showthread.php?3756-The-Leans.&p=36621&...

Hope it helps!

• ▶ Reply

Permalink Reply by Kári Davíðsson on August 28, 2011 at 2:21am

Good job Henrik.

Neither you nor Jose seem to pick up anything at the higher frequencies.
Again my (now dead) frame was particularly loose and bad construction so that could be the reason for me picking up stuff in the 1kHz-2kHz range. It could also be a programming error in my measurement/sampling code (which is unlikely since I only write perfect code :)).

Using the higher order analog filters (at 90Hz) did make it flyable. The attachment of the analog filters was not straight forward so I did not do any extensive flying with them attached. But with the limited flying I did the frame was stable compared to having only the normal AA filter in place (it was unflyable with the normal AA filter). If I set the high order analog filters at 50 Hz it was unflyable again. I did not analyze why but I suspect nonlinear phase of the filters was kicking in. I don't think that the copters need any thing above 10-20 Hz signal to be able to fly. (Think about it 20Hz is 20 rotation around any axis of the copter per seconds.)

On the other hand the DCM is very sensitive to the sampling rate. It does not make any assumption of the frame. It is a linear approximation of a nonlinear problem and the only way it works is that if the dT (sampling time/integration time) is kept as short as possible. The shorter it is the better the linear approximation is. So the relatively high sampling rate is due to the DCM more than anything else I think. I am sure someone will correct me if I am wrong.

Another effect of having very high oversampling factor is that all AA filters can be implemented with linear phase FIR filters and made very sharp due to the high oversampling. E.g. the helicopter people must have a hard time, since their rotor rotates at much slower rate than the direct drive in the multirotors. This means that their noise source is much closer to the working bandwidth of the system. This again calls for very sharp LP filters with linear phase.

Bill Nesbit has done this approach, i.e. very high oversampling to work with the sensors anomalies. I am not sure how he got to the conclusion to do it like that. He is using some ARM cpu which can handle the load nicely.

I was starting to play with coprocessor idea to put in between the oilpan and the apm. Basically implementing oversampling and FIR AA filtering for all the ADC channels on the oilpan. But due to time problems I have not had the time to finish it. It is still on my desk and I will probably finish it someday. The basic idea is to have a cpu with two SPI ports would sit in between the ADC and the A2560. It would do all the oversampling and AA filtering and present the processed data to the A2560. It could even be made to behave like the ADC calling for minimum change in the arducopter code.

• ▶ Reply

DeveloperPermalink Reply by Olivier ADLER on August 28, 2011 at 2:58am

 

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.

 

 

• ▶ Reply

Permalink Reply by Kári Davíðsson on August 28, 2011 at 3:22am

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.

 

• ▶ Reply

• ‹ Previous
• 1
• 2
• 3
• Next ›
• Page