2
\$\begingroup\$

I am building a TriCopter based on the FEZmini .Net Micro Framework.

I have an ADXL345 triple axis Accelerometer and an ITG3200 triple axis Gyro which I am interfacing via I2C.

I am able to get data from the two sensors and they seem to be working fine. What I am having a hard time with is finding a filter that can successfully fuse the two sensors data together into useful IMU data.

I have converted the Kalman Filter presented by Varesano.net to c# but without any useful results. The filter simply does nothing when the IMU moves.

I also converted the complimentary filter presented by nuclearprojects.com to c# with more success, but not complete success: Although the X and Y values are stable, the Z axis keeps rotating fairly constantly, which means I have no good data for Yaw of my TriCopter.

If you need more background on my project, please let me know or have a look at my project on my site at: http://bit.ly/TriRot

Any help would be much appreciated.

Thanks in advance

Gineer

\$\endgroup\$
1
  • \$\begingroup\$ Neat project! It will be interesting to see how .Net MF fares in this use case. I'm curious, though, why you linked your site through bit.ly, instead of the perfectly readable sites.google.com/site/gineer/trirot URL. \$\endgroup\$ Commented Aug 10, 2011 at 16:57

2 Answers 2

Reset to default
2
\$\begingroup\$

Assuming that the conversion of the algorithms you used was correct, I would suggest the Kalman filter. However, the issue you are going to face is that the .NET Micro framework will not run the cycles fast enough to fuse the sensor data and prevent drift or provide stable results; this will be especially true once you put the other runtime code on the processor. You might squeeze 20-30hz out of the processing loop if it is exclusively fusing the data.

Arduino is not running managed code and is optimized by the compiler giving it the extra edge needed to make a semi functional copter as you can see on youtube. Still not stable enough for practical use though IMO.

In order to have an effective IMU and killer end product, you'll need to process the fusing algorithm with a separate processor running non-managed code.

If you still want to go down the road of using a .NET micro based copter for the core flight control (which I am doing myself), take a look at the new Invensense MPU-6000 which does the sensor fusion onboard and effectively offloads the calculations from your managed core processor.

http://invensense.com/mems/gyro/mpu6000.html

\$\endgroup\$
5
  • \$\begingroup\$ Fascinating that you can't get performance as high as an Arduino with a 72MHz, 32-bit ARM processor, even with the overhead of managed code. It should blow the 16 MHz, 8-bit AVR on the Arduino out of the water! Does the .NET Micro framework let you dip into assembly or C for low-level stuff like this that needs to be fast? \$\endgroup\$ Commented Aug 10, 2011 at 16:53
  • \$\begingroup\$ Also, please refrain from leaving signatures or taglines. Your profile is linked in the bottom right corner of your answer, and you can edit your username, change your picture, or add other information: Answers should be about content, your profile is for personal information. \$\endgroup\$ Commented Aug 10, 2011 at 16:55
  • \$\begingroup\$ @Kevin. Thanks for the tips on using the site. I didn't mean to imply Arduino blows the .NET board out of the water - not the case at all. You cannot drop the assembly on the .NET Micro without significant effort (it's nothing like unmanaged in .NET). I meant to make it more clear that the IMUs will not run particularly well on the ATMega either, it's still a watered down version of the filters in the ones I've seen work at all. In case you missed it, in the link provided by op, the sensor fusion was done on the PC. \$\endgroup\$ Commented Aug 10, 2011 at 17:40
  • \$\begingroup\$ You're welcome! We work hard to keep the site consistent and high-quality, so you can expect little comments on use every once in a while. Feel free to ask a question on the meta site or go to the Ask-a-mod chat room if you're curious. Also, the various help texts scattered around the site are often actually useful, the FAQ is definitely worth reading. Thanks for dropping by, your expertise in this area is appreciated! \$\endgroup\$ Commented Aug 10, 2011 at 17:50
  • \$\begingroup\$ Also, with respect to the speed differences, I was just trying to say that the ARM should be significantly faster than the ATmega, so the converse (even in small amounts) is interesting. \$\endgroup\$ Commented Aug 10, 2011 at 17:54
1
\$\begingroup\$

I have done this a while ago at university but with a dsp, I chose a dspic as I was familiar with the coding environment. Anyways as Ryan McGarty answered you are going to have a bit of trouble getting the kalman to calculate fast enough, you might can collect the data fast enough with a arduino, but you are most likely going to have such a slow update time as to make the project useless. You will need to be able to do lots of floating point multiplications, and with dsp you can make these happen over one clock cycle, on a arduino the time needed depends on the complexity of the multiplication.

Further there is a lot of really good information about Kalman out on the web, that is attempting to do this same thing. I haven't looked into it but I assume that the DIY Drones project is doing this.

Why do you need sets of three sensors? My assumption before was you only need 2 pitch and roll, and perhaps another compass or gps for the heading.

Further the project that I was working was a subset of a sensor that is used in helicopters to log flight data, they use a kalman.

Of course you can output your data to a sd card and interpert it later or you can push it out to a computer and run what ever program you would like to do what you want with it, we used labview, but there are some really neat advancements with openGl and processing that I wish were around when I was working on the project.

Also, I am not completely sure what the issue is but I remember there was a problem with the data when you orientate it and get the trig functions to asymptote on the tan function, I would look into it when you are coding and try and find a case where the tan function does something weird depending on orientation.

Here is a video I made about it back in 2008 http://www.youtube.com/watch?v=En6buPWoQ7M

\$\endgroup\$

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.