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.

Replies to This Discussion

I didn't used FPGA since about 7 years, but at this time it was from 5$ each for smallest ones by 1000 parts quantity, to about 100 $ for mid sized ones.

Big multi millions gates FPGAs can cost $$$, more than 1000 or 2000$. They are used for example on high speed provider routers and switches, they have 10 Gbps or faster serial transmitters inside, Obviously we don't need such a high end FPGA.

The cost of the APM / IMU board using only one central FPGA could be the same. FPGA processing power since 7 years as certainly grown.

I'm not affiliated at all with them, but i would recommand Altera chips, because the learning curve seems to me quite soft compared to competitors.

Programming the board would be simpler as well, because all processors and logic circuits would be in the same chip, no more ISP or JTAG port for each processor.

It is possible to program custom instructions for FPGAs embedded processors. I think this is very usefull for signal processing, when external logic is needed for fast FIR for example.

The NIOS 2e embedded processor could be specially interesting, because there is no licence cost. According to Altera :

"Altera specifically designed the Nios® II/e "economy" processor core to use the fewest FPGA logic and memory resources. It is now offered free, no license required, with Quartus® II software version 9.1 and later. The Nios II/e core has higher performance but is in the same cost class as a typical 8051 architecture, achieving over 30 DMIPS at up to 200 MHz, and using fewer than 700 logic elements (LEs)."

Parallel processing is very impressive when using FPGAs. We can get almost the same speed than using dedicated logic circuits, but with great flexibility because all changes are possible wihtout hardware modifications. The hardware design is simpler in the end. Just connect everything to the FPGA pins, and manage everything else by software programming.

I've been playing with Xilinx FPGAs such as the Spartan 3E and had some similar thoughts. ISE Webpack is also free along with the Picoblaze softcore. There are numerous cores available on http://opencores.org such as an AVR processor core. It is cool to consider creating serial ports, USB interfaces on the fly in VHDL "software". Doing the digital signal processing in FPGAs is an intriguing idea.

I really agree on the FPGA ideas! Much more flexibility and foremost: the optimal performance! Choosing the right FPGA and operating frequencies could enable us to use the full 200kHz capability of the ADS7844 (the ADC unit of the Oilpan). Which would allow for silly high oversampling = much better "dead reckoning" and altitude hold assist.

But as much as it is tempting, not having worked much with real FPGA's, aren't there a lot of development obstacles making the open source idea falling a bit? And just the BGA packages introduces problems at first. I'm not saying it's not doable, but it would take a lot for the current development to stretch out of the extremely user friendly Arduino environments.

As I get it however, the Cortex/ARM stuff is more than capable of what we want to accomplish, and I think that they are the right choice in the end after all. Atmega's = too slow/low capacity, FPGA's = too complex, excessive overhead. Besides I think the ARM architecture already feature built-in FPGA's that the user don't need to bother with and also there's the Maple stuff going on Arduinofying the ARM/Cortex processors.

The Atmega's got 16-20 MIPS at absolute maximum, while the STM32 Roberto (and me/others on AQ in another fashion) developed for has a maximum of 90 DMIPS (integer MIPS), and the ARM/Cortex8 has 2000 DMIPS.so there's plenty of easily accessible power if we want it.

But you have only one processor. Realtime tasks are not easy to do on a single chip as soon as you have many tasks running at the same time.

Even if you can get it working, jitter will be high because alternate tasks will delay realtime tasks.

For example, actually Roberto has a big problem on the STM32 : there is no 9 bits hardware mode for the serial transmitter. So Jeti compatibility is not possible without using big banging... And bit banging would seriously degrade performances. Perhaps that STM32 support is great, but ST will not add 9 bits support for Roberto. This is a big problem because Jeti is the best option for telemetry directly on the transmittter (open protocol and possibility to add menus on the transmitter telemetry screen).

If you have an FPGA, in this case, just add a serial transmitter to the design and you are fine. You can design one with 13 bits if you need it...

More an FPGA is not limited to one processor. You can add as many processors as you need inside, if you stay inside the gates number limit.

Multiprocessor designs are much more powerfull and reliable than mono processor designs.

I've found that FPGAs are not really complicated to program. But sure there are drawbacks. The cost of devolopement kits is higher, and there is a learning curve.

For realtime tasks, FPGAs can be faster than DSPs, because you can design custom logic circuits to do the job. So for sure 200 KHz is low frequency for an FPGA.

Yeah, well this is certainly a double edged sword full of counter considerations! On the one hand, you have the possible performance and flexibility which comes with great change, on the other hand you have the comfortability and usability with very developed open source tools that common Joe can easily use and adapt, at the cost of flexibility and performance.

The argument of the 9-bit serial link to that telemetry system might not be a big consideration I think, I think that's rather a extension that needs to be dealt with separately (why not look up a equally good system that uses standard protocol?), but the multitasking is a seriously interesting aspect. Lego NXT solved some of it by adding a coprocessor (Atmega) to the main ARM.

Don't get me wrong, I'm totally excited to get into FPGA design for real (had a job opportunity coming up about it this week actually!) and I see all the advantages of it. Yes - as I understand it, they can be configured for far higher capability than specifically made DSP's.

But you also gotta remember what the application is. For these kind of projects, I think that the best option is to keep with what's in our time so to speak. To use readily available tools that many have experience with so that more people can take part in development. Otherwise I think we'll see a stagnating group of people in dedicated development and diversity is lost. That's a totally different aspect of this project. Which I think is very important, because that's what makes it what it is.

Of course, if I would design the most high-end multicopter - no costs considered - I would definitely be doing it with FPGA's! But there's other considerations too as said. While we're on the subject: what would be the best FPGA w/ accompanying development tools to get for a start in the same manner as we're using the Arduino's? Are there any ones that are less expensive and more open/comprehensible?

I'm not sure that the FPGA would be a great handicap for opening. After all, as soon as you embedd one or more controlers inside it, you get normal C++ programming, like we can have for the ppm encoder or the main actual AVR.

The FPGA core programming would be done by a couple more experienced peoples.

The situation would not be very different than actual one, where only a couple peoples are working on very advanced things like hardware design and low level programming.

Again, the great advantage is flexibility, and the possibility to add logic blocs to get parallel processing for simple realtime tasks or hardware tasks like ppm encoding. This is a great safety for the futur of the project.

Look at actual situation : it is not possible to get really higher performance without changing the core controller. With a FPGA it would have been possible to externalize some high speed tasks to external logic blocs, so that main processing power can be economized.

"But you also gotta remember what the application is. For these kind of projects, I think that the best option is to keep with what's in our time so to speak. To use readily available tools that many have experience with so that more people can take part in development. Otherwise I think we'll see a stagnating group of people in dedicated development and diversity is lost. That's a totally different aspect of this project. Which I think is very important, because that's what makes it what it is."

Well, you may be absolutely right that we could have a small group of people doing the very low stuff such as implementing (or at least finding and testing) the core CPU/DSP and then when an interface has been laid upon that it should make able for everyone else to work in the higher levels as we usually do.

Do you know what tools, both hardware and software tools, would be for a hobbyist project like this though?

7 years ago, i did a product study for a project and i found that the easier products was Altera ones. At this time, Quartus II was very friendly. It had a goog GUI with a graphic design engine and a Logic component library, with almost every logic circuit you can imagine. So it was possible to design logic circuits without writting a line of VHDL or Verilog code (VHDL and Verilog are the high level languages for logic circuits programming).

For advanced projects, it was recommanded to learn VHDL or Verilog programming, so that you could extract the full power of the chip.

I think that only Cyclones are in the price range of a hobby product. But this need to be checked with an application enginneer as the prices could have changed since 7 years !

What need to be checked as well is the licencing scheme, to know if all needed tools are availables in the base product, and if not, the price of additive programming software or intellectual property libraries we could need to speed up the project.

The programming sofrware is Quartus II. And there are developpement kits with a populated board so that you can start to design your first circuit just after reading the getting started manual. Really not more complicated than programming an AVR. I would say that basic stuff is really easier than controller programming.

I remember the first thing i did is put a couple "OR" gates, assign them to push button inputs, and light a LED with the OR gate output :=)

I think that discussing with an application enginneer is the first thing to do, before to start buying a developpement kit as the choice is quite large, from 5$ devices to multi k$ devices, with or without high speed serial transceivers, with ot without ARM hardware helper, with or without Gold PLL inputs, and some other important hardware aspects like Logic element number, max clock frequency, pins number...

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!

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.

I changed my forum name so that it's easier for users and team people to make connections.

Sure it's feasible, perhaps not with a 5-10$ chip (if we need to embed 3 or 4 AVR core or other controller or a Floating point hardware unit).

Sure it is possible to embed an ARM inside, or even get a hardware ARM inside, but the price will rise because of IP or hardware price. Do we really need the power of an ARM ? It seems to me that we have many small taks to process, in this regards it could be more efficient to have 2, 3 or 4 small embeded controllers, eventually helped by custom instructions using embeded logic blocs.

There is a quite heavy preparation work to do for sure, needing good communication with programmers and hardware designers, and with an Altera and / or Xilinx application engineer to choose the right target chip.

I'm not sure that the board would be really bigger than actual boards. Small and Mid sized FPGA packages are not so big.

The FPGA model need to be carefully choosed, to get the power we need for actual and futur needs. Perhaps that the software side is even more important to carefully check, because FPGAs do have many commercial options (IPs modules and programming software options). This need to be carefully checked to be sure that options that could be needed are not out of price range.

Then modularity of hardware will take all his importance because a core FPGA board could have a really longer life expectancy than classical controller boards thanks to his flexibility and processing power.

A fast extension bus like CAN or other modern digital bus could be used so that extensions boards could be added without bus speed restrictions and without redesigning the core board each time. The IMU could be linked like this as well as other I/O board for specific needs like interfacing RC receivers, more I/O or servo output needs, telemetery board...