Hi there! Finally you can pre-order the ArduIMU V3 here.. You can find more info abut it in my last post here.
The final version of the board for full production is here, I'm expecting to start shipping them this Friday or Monday.
We are still working on documentation and giving the final cosmetic touches to the example code to have it ready before you have one in your hands and at the same time we are shipping samples to developers to do a full DCM integration.
From now on our new color will purple! All our new products will feature a Lilypad style look!
(Note: this is a stand-alone IMU, and is not designed to be a replacement for the "Oilpan" IMU shield of ArduPilot Mega.)
Comments
Alex: It's totally up to the user. They can either do the sensor fusion in the Atmega (as we currently do) or let the MPU-6000 do it and free up computational resources. The code supports both.
One and only...
Is it work with Paparazzi AP?
P.S.
Excellent job!
ArduIMU is not meant to be a full fledged autopilot system. But they are great for those special R/C or robotics projects where you need some kind of stabilization combined with custom servo mixes. Myself and others have built and flown quad's using just the ArduIMU boards (V1&2) and a receiver with PPM output. Whenever I do some kind of experimental R/C aircraft I usually end up using the ArduIMU as a 3-axis head-hold gyro with some custom servo mixes for the job to keep something otherwise unflyable up in the air.
@Paul, I think there will be another product comming along for apm. This seems to be a general product for anyone wanting to experiment with motion processing apps such as camera tracking, handheld, or things like lagacy ap. I think it has a great many uses. I do plan to use it with apm but not with the standard apm or apc code. (edit) John speaks well :)
@Alex: The MPU-6000 / ATmega DCM is more of a hybrid solution. The main problem with a pure AVR8 based DCM solution is that the ATmega's are just not fast enough to do proper data sampling/filtering and DCM calculations at optimum refresh rates. The MPU-600 motion engine helps offset this by doing most of the preprocessing of sensor data as well as some of the math required for a DCM solution. But if you want, you are still free to get raw data from the MPU-6000 and do all calculations in the ATmega using the current/legacy DCM solution. Just don't expect the same performance as with the hybrid solution.
I thought Jordi said there are some options. With the 328 on board you should have a great deal of control to decide how you would like to process the data. I am sure you can get raw sensor values and use 328 for dcm but I want to explore what the 6000 can do.
@Fab--I was thinking of APM with its built-in IMU and wondering how this board would be used. I didn't think about the legacy ArduPilot, but being legacy, wouldn't be expecting ongoing development of hardware to support it.
Well, I certainly hope that any kind of data preprocessing or even fusion on the MPU-6000 will be strictly optional. I'm pretty sure you can always read the actual raw data registers.
If the MPU-6000 is doing a black-box DCM calculation internally, then my level of interest in this board goes from 100% to 5%. Will the board support running the DCM calculation on the Atmega?
@Paul, are you talking about legacy Ardupilot and not APM? If so, then the Ardupilot shield can work with thermopiles attached but as a more accurate alternative the imu can be used with the serial connection. It sounds like Jordi is making the software for the imu so that it can be used with old style AP but this is not entirely clear. In any event it is not a big job. If I recall the shield on the old ap provides thermopile, air speed and gps. If you don't need air speed then you will not need the shield, just ap and imu.