Mindboards

On most of the integrated IMU chips there are only singular seperated sensors:
the Gyro can calculate only 3D rotational speed,
the Accerlerometer can calculate only 3D acceleration,
the Compass can calculate only 3D heading direction.

Most of all IMUs are only providing these three primary output values 3D rotational speed, 3D acceleration, and 3D heading direction, mostly they are cleaned of sensor noise (Gaussian and non-Gaussian noise like sensor drift) by sensor fusioning and filtering by stochastical Filters (e.g., Kalman) - but they still are three seperated 3D values (3*3D = 9D vector)

Digital Motion Processing means, that out of these primary values all secondary navigation values are calculated by an embedded MCU, so you can directly poll

current 3D position (x, y, z) in space (related to a start point),
current 3D speed in space (^x, ^y, ^z )
current 3D spatial orientation (roll, pitch, yaw)

this is what the MPU-6050 / MPU-9150 are supposed to provide.

Helmut,

Do you think, with your advanced grasp on math, you would be able to duplicate the functionality of such a device, given the inputs of an IMU?

= Xander

of course I would if I could, but my math skills are only elementary.

Even the filtered primary IMU sensor values have to be progressed - by a secondary stochastical sensor fusioning - to a spacial state estimation.
Notice, that even a cleaned compass value still suffers from magnetic deviation by magnetic disturbances e.g., by ferromagnetical influences of the room (reinforced concrete, pipelines, power cable) and electomagnetical disturbances on the robot itself. In such environments, e.g. the magnetic heading would change sometimes faster and sometimes slower than the gyro heading which would severely interfere the navigational results and thus will have to be filtered by additional stochastical processings.

Here I have to give up.

But as the developers of these IMU DMP chips just need to develop all the math only once for billions of identical chips these efforts would be more justified and worth while (and for the MPU-6050 / MPU-9150, the company claims that they have already achieved this).

ps,
the info was rather obscured but this following link you posted for the LSM9DS0 sensor seems to show also partial DMP functionality (not sure if it can be accessed by NXC):
http://www.st.com/st-web-ui/static/acti ... 087365.pdf
one will have to see....

The iNEMO is still in Beta, but they claim it is immune to magnetic error and has 4 different software packages.
http://www.st.com/web/catalog/sense_pow ... 8/PF253162
This software is platform independent.
http://www.st.com/st-web-ui/static/acti ... 038065.pdf

THE DSP thing can be done on the NXT. Here are three clips that I shot using a IMU sensor. I do not think a compass was included while I shot the clips, but it currently is. Sorry for the poor quality, you'll have to watch the NXT screen carefully. On it you'll see a compass rose or an image of the sensor floating in a 3D space.








The DSP is implemented in Lejos and does over a 100 iterations a second in 9DOF mode still leaving CPU time for other serious processes. I explained the workings of the IMU filter on my blog.

The 9150 and 6050 are still not documented for the general public. The iNemo is very promising but still not available to the general public.

Evaluation software has been downloaded for the iNEMO and the available STEVAL-MKI108V2L3GD20 and LSM303DLHC 9 axis module for a standard DIL24 socket which was also purchased.
http://www.st.com/web/en/catalog/tools/ ... pe=keyword#

.@ aswin0,
thx for sharing the videos but first: I don't understand lejos code.
Then, 2nd: As far as I can see, you only use a gyro, but I need additionally accelerometers which are needed for horizontal straight, transversal, and vertical movement calculation, and a compass for filtering gyro drift/noise and accelerometer noise.
That means that I need:

a 3D Gyro
a 3D Accelerometer
a 3D Compass

to process:
current 3D position (x, y, z) in space (related to a start point),
current 3D speed in space (^x, ^y, ^z )
current 3D spatial orientation (roll, pitch, yaw)

That's a little bit more complex than I can see from your videos (please CMIIW).

Additionally, the DMP program must not require more than 1k on the NXT flash because the rest of the NXT memory is needed for my move control program, and much MCU calculation power is needed for several real-time PID regulators.
(For the moment it's only in 2D (my map and explore robot), but it is planned to use it in 3D for an autopilot for a quadrocopter or an aircraft, too.)

And the more the DMP-IMU can calculate on his own, the better for the NXT's real-time-performance.

Hey Doc,

I know of your complicated relation with Java. I do not have a solution for that (not that you asked for one).

The IMU filter you see in the clips is a full blown 9DOF filter. It uses the three sensors you mention and outputs position (as in tilt and heading), rotational speed and linear speed. The same kind of filter is used in Ardupilot and Arducopter.
However, the filter is not fit to base speed or position on. It suffers from integration error. It shares this drawback with all other 9DOF DSP's including MPU9150 and iNemo. Only when you include a GPS or any other sensor that uses an external reference for positioning you can create a system that gives reliable position and speed information.
Also, the filter does use substantial CPU power and takes more than 1K memory.

a compass indeed is using an external reference, that's why it's so important and powerful in conjunction with stochastical filters (EKF, SMC) to calculate the localization.
In your clips it looks like as if you used a HT Gyro (1) and a Dexter gyro (3), didn't you? (Not sure what you show in the 2nd video.)

But anyway, I'm not able to construct a EKF or a SMC filter for sensor fusioning of all 3 sensors for positioning, and got not the cpu power and not the memory to do it besides all other stuff.
The NXT is too much limited for that (you can't even make a SMC filter run on the NXT with NXC in real-time).

So that's why I'm interested in using a DMP-IMU which is able to do all these things by itself without straining the NXT.

doc-helmut wrote: In your clips it looks like as if you used a HT Gyro (1) and a Dexter gyro (3), didn't you? (Not sure what you show in the 2nd video.)

Clip 1 and 2 show a home brew IMU sensor housed in a sound sensor case, clip 3 shows a Dexter Industries IMU sensor.