IMU sensor feat. digital motion processing
Re: IMU sensor feat. digital motion processing
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.
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.
Last edited by HaWe on 11 Aug 2013, 08:46, edited 2 times in total.
Re: IMU sensor feat. digital motion processing
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
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
| My Blog: I'd Rather Be Building Robots (http://botbench.com)
| RobotC 3rd Party Driver Suite: (http://rdpartyrobotcdr.sourceforge.net)
| Some people, when confronted with a problem, think, "I know, I'll use threads,"
| and then two they hav erpoblesms. (@nedbat)
| RobotC 3rd Party Driver Suite: (http://rdpartyrobotcdr.sourceforge.net)
| Some people, when confronted with a problem, think, "I know, I'll use threads,"
| and then two they hav erpoblesms. (@nedbat)
Re: IMU sensor feat. digital motion processing
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....
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....
-
- Posts: 8
- Joined: 09 Aug 2013, 04:50
Re: IMU sensor feat. digital motion processing
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
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
Re: IMU sensor feat. digital motion processing
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.
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.
My blog: nxttime.wordpress.com
-
- Posts: 8
- Joined: 09 Aug 2013, 04:50
Re: IMU sensor feat. digital motion processing
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#
http://www.st.com/web/en/catalog/tools/ ... pe=keyword#
Re: IMU sensor feat. digital motion processing
.@ 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.
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.
Re: IMU sensor feat. digital motion processing
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.
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.
My blog: nxttime.wordpress.com
Re: IMU sensor feat. digital motion processing
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.
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.
Re: IMU sensor feat. digital motion processing
Clip 1 and 2 show a home brew IMU sensor housed in a sound sensor case, clip 3 shows a Dexter Industries IMU sensor.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.)
My blog: nxttime.wordpress.com
Who is online
Users browsing this forum: No registered users and 0 guests