Forget about Kalman filters. This baby needs a neural-net processor (a learning computer). I'm thinking a MCU married to a low cost FPGA. Then it needs a 3-axis accelerometer and a 3-axis gyro for 6-degrees of relative freedom; and 3-axis magnetometer and gps for 6-degrees of absolute freedom (referenced to the earth).

The GPS should have PPS break-out so that you can log time-stamped data to an SD card. You could add some environmental sensors (temperature, pressure, humidity) so that sensors that drift with respect to temperature (for instance) can be dynamically calibrated.

Finally, if you really feel like going overboard, add some camera sensors so that people can play around with optical INS stuff.

If you print a nice big feducial marker on the board, you could use a web camera to calibrate it.

I'd actually like to call it 'Ultimate IMU,' but I'm sure we'd get slammed for that. Any good ideas?

evarobotics wrote:How will it compare with your 9DoF Razor IMU?

Similar in that it will have 9 degrees of freedom; a different gyro will be used and it will have an ARM core. It will also be Xbee ready and GPS ready. Possible additions are USB mass storage and a pressure sensor adapter, but these haven't been finalized yet. Hopefully it will have a good base code that runs some filtering or AHRS code to come standard.

evarobotics wrote:When do you hope to have it available?

Ah, this is a question I can not answer. Sorry, but priorities change very quickly around here; I'm working on it now but there are always unforeseen delays and higher priority projects. Giving a timetable often leads to frustration and the accusations of 'vaporware.' We'd like to offer a better IMU and we're working on it is all I can really say.

The make or break will of course be the supporting documentation. You can give it all the bells and whistles you like but if the interface and code examples are not easy to understand and adapt then your 'Ultimate IMU' will only appeal to a few uber-geeks.

If you manage to avoid the above pit-falls I would be very happy to assist with testing the beast.

Just my 2 cents. I will buy such imu only if:
- I don't need to care about DCM, Kalman or everything more complex than +-*/
- everything is ready, implemented and working, not "blahblahblah ready"
- GPS antena or complete receiver is not tied to the sensor/CPU board. Applications are not always RC models.
- IMU is easily configurable with simple tools.
- Com interface is ttl serial, RS232, RS485 or CAN.
- Additional PC software for test and display doesn't need Matlab, Labview or such expensive software.

Personally I'd like to see a low cost, all-in-one autopilot for small foamies. My $0.02:

- Attitude estimation: Invensense IMU-3000. It's a 3-axis gyro with built-in quaternion-based sensor fusion (I'm assuming Kalman filtering, as DCM is obviously a matrix algorithm, and I haven't seen a quaternion-based complementary filter either). Two I2C ports connect to an external 3-axis accelerometer and an MCU. The chip reads the accelerometer values directly without intervention from the MCU, which can read attitude estimates on the other I2C. Couldn't be simpler, and you don't need a high-powered MCU. It's not out yet, but we're promised that evaluation boards are coming soon. Perhaps Sparkfun can inquire with Invensense directly? http://www.invensense.com/mems/gyro/imu3000.html

- MCU: I love STM32, but anything ARM is nice. Too many electrical engineers just slap whatever chip has good electrical characteristics onto a board without thinking of the needs of us poor software developers. We need a proper compiler, darnit! This means AVR, ARM, PIC24, MSP430. No MSP430x, GCC doesn't work (no really, it doesn't, you may think it does but holy crap don't get me started). Stuff like PIC18 is right out imho. Since the IMU-3000 does the sensor fusion, the micro needs only to implement some relatively simple control loops. Given the fact that an STM32 or LPC costs about the same as a capable AVR, I'd go for the ARM - that way I can run an embedded rtos like eCos so that I can at least have memory protection. Sucks to have your plane fall out of the sky because some led blinking code is trying to write to *random. Also, the first person to suggest Arduino will be stabbed with a pencil :3

- Telemetry: why pay craploads of money for an XBee module when you can just put a CC1101 433MHz radio and SMA connector on the board? This way you can have plane-to-ground and plane-to-plane communication: flying multi-hop networks, yay! Note that the CC1101 is a packet radio, so you clock in your data and press send, very easy to work with. Personally I'd even do manual control over such a digital link, saves a receiver and PWM/PPM decoding logic.

- Shields/extending: I really like the small footprint of the XBees. Seeed is selling a GPS bee (http://www.seeedstudio.com/depot/gps-be ... p-560.html), and they also have a bluetooth bee. Having one or two %sbee connectors on the board would allow for stuff like adding extra sensors/actuators such as compass, magnetometer, pitot tube, temperature, camera, gps, led lighting, etc.

- Stick on some debug leds, and one or user two buttons. Four servo channels and one or two motor controls? Four for quad copters of course.

Now given these requirements I think the whole thing should be possible to sell for about $100. I'm not sure what the IMU-3000 will cost, but their sales blurb quotes ~$3.50 for large quantities - so they can't be more than 10 bucks if you buy a few. Add to that a capable MCU, accelerometer, CC1101 ($5), and you can easliy have a parts list of under $50. Add another $50 for development cost, PCB manufacturing, labor, profit. I'm not a professional electrical engineer at all, so I'm not sure if I'm talking out of my ass here, please correct me if I'm sounding completely unreasonable.

Now let's see what that would mean for low-cost UAV enthusiasts like me:

It could contain an ARM cortexM3 processor . I use STM32 , but I could use a LPC17xx. I will not come back to an old ARM .

The remaining communications ports should be available , at least 1 comm port for a GPS , 1 comm port for the comm toward other sytems, and an SPI.
few ADC IOs could be available to connect other sensors ( pressure...)

For the software side , if libraries were available to access the sensors , that could be a plus , but not really necessary. And maybe a forum , or an open source project could share experience between people.

evarobotics wrote: I'm keen to learn more about the data fusion algorithm you used. Do you have a paper I could see?

You can download a technical report on the data fusion algorithm at: http://code.google.com/p/imumargalgorithm30042010sohm/. This report describes an algorithm I developed, but the algorithms I now use and recommend to others are (quaternion implementations of) Mayhony’s (IMU) or Mayhony’s mixed with mine (AHRS); see URL.

Thanks for the links - I have also forwarded these onto a mate doing some UAV work.

There are now countless IMU and AHRS products available for <$200. I wonder if SparkFun are losing the enthusiasm to get involved in this increasingly crowded Market (I hope not).

I'm afraid we are coming to the same conclusion. There are SOOOOOOO many IMU's being developed using essentially the same algorithms, features, and hardware we would. Anything developed anything now risks becoming just another me-too product.

Sparkfun could still have a good shot at it because they have an established market and good reputation.

Heck, that entire drone with iPhone app for $300 will be available soon!